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ПРЕДИСЛОВИЕ СКОТТА МЕЙЕРСА 


В 1991 году вышло первое издание книги “Эффективное использование С++” 
(“ЕНесйуе С++”). В нем почти не рассматривались шаблоны, поскольку в то время 
они были новшеством, и я о них практически ничего не знал. Включенные в книгу 
немногочисленные фрагменты программ, содержаших шаблоны, я был вынужден по- 
сылать по электронной почте другим людям, поскольку все доступные мне компиля- 
торы их не поддерживали. 

В 1995 году я написал книгу “Наиболее эффективное использование С++” (“Моге 
еЙесиуе С++”). И снова почти не упомянул о шаблонах. На этот раз меня остановило 
не отсутствие знаний (в первоначальном варианте книга содержала целую главу, по- 
священную этой теме) и не ограниченность моих компиляторов. Просто возникло по- 
дозрение, что понимание роли шаблонов в среде программистов на языке С++ пре- 
терпевает настолько значительные изменения, что все Мои мысли по этому поводу 
могут быстро стать банальными, поверхностными и даже ошибочными. 

Эти подозрения возникли по двум причинам. Первой из них была статья, опубли- 
кованная в январском номере журнала “С++ Кероп” за 1995 год Джоном Бартоном 
(Јоһп Вапоп) и Ли Нэкманом (Іее МасКтап). В ней описывалось применение шабло- 
нов для безопасного анализа размерностей (уреза Фітепзіоп апа1уѕіѕ) без дополни- 
тельных затрат машинного времени. Я сам довольно долго пытался решить эту задачу 
и знал, что другие программисты также безуспешно ломают над ней голову. Револю- 
ционный подход, предложенный Бартоном и Нэкменом, помог мне понять, что с по- 
мошью шаблонов можно не просто создавать контейнеры, содержашие объекты клас- 
са Т, но и достичь намного более значительных результатов. 

В качестве иллюстрации этого подхода рассмотрим код, предназначенный для ум- 
ножения двух физических величин произвольной размерности. 

тетр1ате<іпт ті, іпт 11, іпо 11, Тит м2, іпо 12, їпо 12> 


РНу$1са1<т1+т2, 11+12, 21-52» орегатог* (РНу$1са1<т1, 11, %1> 11$, 
Рһуѕіса1<т2, 12, 12> гИ5) 
{ 


гетигп Рһуѕіса1 <м1+т2 ,11+12,11+12>:: 
ип1 “115$ . малие () *7ћѕ.ма1ие0) ; 

) 

Даже без объяснений, приведенных в статье, совершенно очевидно, что эта шаб- 
лонная функция (Тапсіоп іетріате) получает шесть параметров, ни один из которых 
не представляет собой какой-либо тип! Это явилось для меня приятным открытием. 

Вскоре я стал изучать стандартную библиотеку шаблонов 5ТІ, (Мапаага Тетріаїе5 
Пібгагу). Эта разработка Александра Степанова (Аіехапаег 5герапоу) весьма элегантна. 
В ней контейнеры ничего не знают об алгоритмах, алгоритмы ничего не знают о кон- 
тейнерах, итераторы функционируют как указатели (но могут быть объектами), кон- 
тейнеры и алгоритмы одинаково успешно могут получать указатели на функции и са- 
ми функции в виде объектов, а пользователи библиотеки могут расширять ее, не при-. 
бегая к наследованию от какого-либо базового класса или переопределению 
виртуальных функций. И тут я почувствовал (как и при чтении статьи Бартона и 
Нзкмена), что практически ничего не знаю о шаблонах. 

По этой причине я не стал почти ничего писать .о шаблонах в книге “Более эф- 
фективный С++”, Как я мог касаться этой темы, если мое понимание шаблонов ос- 


тавалось на уровне контейнеров, содержащих объекты класса Т, в то время как Бар- 
тон, Нэкман, Степанов и другие продемонстрировали, что такое применение шабло- 
нов является лишь вершиной айсберга? 

В 1998 году Андрей Александреску (Апӣгеі Аехапагезси) и я стали обмениваться 
сообщениями по электронной почте, и вскоре я понял, что мне придется снова изме- 
нить свое мнение о шаблонах. В то время как Бартон, Нэкман и Степанов ошеломили 
меня тем, что можно сделать с помощью шаблонов, Андрей поразил меня, объяснив, 
как это можно сделать. 

Одна из простейших вещей, которые он помог мне изложить в общедоступной 
форме, до сих пор остается примером, который я первым привожу людям, начинаю- 
щим работать в этой области. Это шаблон СТАз5егт, представляющий собой аналог 
макроса аз5егт, но позволяющий проверять условия во время компиляции, а не во 
время выполнения программы. 

тепрТате«роо1» $тгист СТАЅЅегї; 

тетр1ате<> зтгист СТАззегт<хгие> {}; 

Вот и все! Обратите внимание на то, что обычный шаблон СТАз55егі нигде не 
определяется. Более того, он конкретизирован только для значения тгие, но не для 
Ға1ѕе. То, что есть в этом шаблоне, не менее важно, чем то, чего в нем нет. Это 
заставляет посмотреть на код этого шаблона под другим углом, поскольку 
оказывается, что большая часть его “исходного кода” осознанно проигнорирована. 
Этот образ мышления совершенно отличается от общепринятого. (В этой книге 
Андрей обсуждает более сложный шаблон Сотрі1етітесһекег.) 

В итоге Андрей приступил к разработке шаблонно-ориентированной реализации рас- 
пространенных языковых идиом (1априаве 1410115) и шаблонов проектирования, особенно 
шаблонов СоЕ!. Это вызвало перепалку в среде разработчиков шаблонов, поскольку они 
были абсолютно убеждены, что эти шаблоны невозможно запрограммировать. 

Когда стало ясно, что Андрей создал средства для автоматического генерирования 
реализаций шаблонов, а не лля программирования собственно шаблонов, возражения 
были сняты. Мне было приятно узнать, что Андрей и один из разработчиков шабло- 
нов СоҒ (Джон Влиссидес) вместе написали две статьи в журнале “С++ Керогі", по- 
священные этой теме. 

Следуя выбранному направлению, связанному с шаблонами для генерации идиом и 
реализациями шаблонов проектирования, Андрей столкнулся с проблемами, стоящими и 
перед другими программистами, работающими в этой области. Должна ли программа быть 
безопасной в многопоточной системе (Іргеай за)? Откуда брать дополнительную память: 
из кучи, стека или пула статической памяти? Нужно ли перед разыменованием интеллек- 
туальных указателей (стай роїпѓегѕ) проверять, равны ли они нулю? Что случится при за- 
вершении программы, если один деструктор синглтона (5іпріоп'є дезіпісіог) попытается 
использовать уже уничтоженный синглтон? Андрей стремился предложить пользователям 
максимально широкий выбор возможностей, не навязывая своего мнения. 

Он решил инкапсулировать эти решения в виде классов стратегий (ройсу сіа55е5), 
что позволило пользователям передавать их как шаблонные параметры. Кроме того, 
Андрей предложил для этих классов разумные значения по умолчанию, так что боль- 


1 Название этих шаблонов происходит от словосочетания “Сапр ої Еошг” — “Банда четырех”. В 
состав этой “банды” входили Егісһ Сатта (Эрих Гамма), Кісһага Нет (Ричард Хелм), Кари Јоһћлѕоп 
(Ральф Джонсон) и Лори \УЙ594е$ (Джон Влиссидес), написавшие основополагающую книгу Дези 
Рапет: Еетеніз оѓ Кеиза Ме ОБес!-Отмете4 Ѕоўһуат (Аййіѕоп-Меѕіеу, 1995). 
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щинство клиентов может их просто игнорировать. Результат оказался потрясающим! 
Например, шаблон для интеллектуального указателя, описанный в книге, получает в 
виде параметров только 4 класса стратегий, а генерирует более 300 разных типов ин- 
теллектуальных указателей, каждый из которых обладает уникальными особенностями 
поведения. Программисты, осведомленные о поведении интеллектуального указателя, 
заданном по умолчанию, могут вообще проигнорировать параметры, представляющие 
собой классы стратегий, указав лишь тип объекта, на который он должен ссылаться. 
Это позволяет им извлекать выгоду из прекрасно сделанного класса для интеллекту- 
ального указателя, не прилагая никаких усилий. 

В конце книги рассмотрены три разные темы, причем для каждой из них выбран 
свой способ изложения. Во-первых, представлен новый взгляд на мощь и гибкость 
шаблонов в языке С++. (Если, прочитав материал, посвяшенный спискам типов 
(Суре! $5), вы не свалились со стула, значит, вы сидели на полу.) Во-вторых, указаны 
ортогональные направления, по которым идиомы и реализации шаблонов могут отли- 
чаться друг от друга. Для разработчиков шаблонов и программистов, занимающихся 
их реализацией, эта информация крайне важна, однако вы вряд ли найдете ее в дру- 
гих источниках. В заключение, читатели могут свободно загрузить исходный код биб- 
лиотеки шаблонов ІокКі, описанной. в этой книге, и изучить ее строение. С ее помо- 
щью вы можете не только испытать свой компилятор, но и начать собственную разра- 
ботку. Разумеется, вы можете вполне законно использовать код, написанный 
Андреем, для своих целей. Я абсолютно уверен, что ему это будет приятно. 


Скотт Мейерс (5сой Меуегѕ) 
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ПРЕДИСЛОВИЕ ДЖОНА ВЛИССИДЕСА 


Что нового можно сказать о языке С++? Оказывается, очень много. Эта книга посвя- 
щена слиянию разных способов программирования — обобщенного программирования, 
метапрограммирования шаблонов, объектно-ориентированного программирования и раз- 
работки шаблонов проектирования — в рамках нового подхода. До сих пор эти направле- 
ния в программировании развивались изолированно друг от друга, и выгоды, полученные 
от их объединения, лишь начинают получать достойную оценку. Это слияние открывает 
новые перспективы для языка С++ не только с точки зрения собственно программирова- 
ния, но для разработки программного обеспечения в целом. Особенно значительно это 
повлияет на анализ программного обеспечения и его архитектуру. 

Обобщенные компоненты, созданные Андреем, поднимают уровень абстракции 
настолько высоко, что язык С++ приобретает черты языка спецификаций проектиро- 
вания (дезівп зресШсаНоп Іаприаве). При этом в отличие от узкоспециализированных 
языков проектирования язык С++ сохраняет всю свою мощь и выразительность. Анд- 
рей продемонстрировал, как программируются концепции проектирования: синглто- 
ны (зіпріеїопез), инспекторы (уіѕИогѕ), заместители (ргохіеѕ), абстрактные фабрики 
(абзігасі Ёасїогіеѕ) и т.п. Можно даже настраивать готовые компоненты с помошью 
шаблонных параметров, не расходуя дополнительного машинного времени. Не нужно 
выбрасывать кучу денег на разработку новых инструментальных средств или изучать 
тома методологической тарабарщины. Достаточно иметь надежный современный 
компилятор (и эту книгу). 

Разработчики генераторов кода долгие годы обещали обеспечить их совмести- 
мость, но теоретические исследования и практический опыт убедили меня, что дос- 
тичь этой цели невозможно. Остаются нерешенными проблемы полного обхода де- 
рева поиска, генерации недостаточно качественного кода, негибких генераторов, 
нечитабельности сгенерированного кода и, разумеется, широко известная проблема, 
которую можно сформулировать так: “Я не могу вставить этот проклятый код в 
свою программу”. Каждой из этой проблем достаточно, чтобы завести программи- 
ста в тупик, а вместе они создают практически непреодолимые препятствия для ав- 
томатической генерации кода. 

Как было бы хорошо получить все теоретические преимущества автоматической 
генерации кода — скорость, легкость реализации, сокращенную избыточность, 
меньшее количество ошибок, одновременно избежав его практических недостатков! 
Именно это обещает подход, предложенный Андреем. Обобщенные компоненты 
(вепегіс сотропепі5) реализуют удачные схемы в виде удобных для использования, 
поддающихся смешиванию и подходящих для решения задачи шаблонов (пихаЫе- 
апда-татспабіє ѓетріаїеѕ). Эти шаблоны делают практически то же, что и генераторы 
кода: создают стандартные фрагменты кода для дальнейшей обработки с помошью 
компилятора. Отличие заключается в том, что шаблоны позволяют сделать это, не 
выходя за рамки языка С++. В результате происходит полная интеграция получен- 
ного кода с исходным кодом приложения. При этом остается возможность исполь- 
зовать всю мощь языка, расширяя классы, замещая методы и подгоняя шаблоны 
под свои требования. 

Некоторые из описанных приемов программирования довольно трудно понять, 
особенно метапрограммирование шаблонов, рассмотренное в главе 3. Однако, освоив 


его, вы сможете постичь всю теорию обобщенных компонентов, которые практически 
сами себя создают. Эти компоненты описаны в последующих главах. Я думаю, что 
метапрограммирование шаблонов, изложенное в главе 3, само по себе достойно от- 
дельной книги. Остальные десять глав освещают способы его применения. Несмотря 
на то что десять глав — это довольно много, ваши инвестиции окупятся сторицей. 


Джон Влиссидес (Јоһп Уіѕѕійеѕ) 
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ПРЕДИСЛОВИЕ 


Возможно, вы держите эту книгу в руках, находясь в книжной лавке, раздумывая, по- 
купать ли ее? А может быть вы пришли в библиотеку и решаете, стоит ли тратить время на 
эту книгу? Знаю, что у вас нет времени, поэтому буду краток. Если вы когда-либо интере- 
совались, как нужно писать программы высокого уровня на языке С++, как справиться с 
лавиной мелких деталей, загромождающих даже самую простую программу, или как соз- 
дать компонент, пригодный для повторного использования, который не нужно разрабаты- 
вать заново для каждого нового приложения, то эта книга для вас. 

Представьте себе такую картину. Вы приходите с производственного совешания, 
неся в руках груду диаграмм, на которых нацарапаны ваши комментарии. О'кей, гово- 
рите вы, тип события, передаваемого от одного объекта к другому, в любом случае не 
сһаг. Это — тип 1п+. И вы изменяете одну строку в вашей программе. Интеллекту- 
альный указатель на объект класса міддег работает слишком медленно, его следует 
сделать неконтролируемым. И вы изменяете еще одну строку. Фабрика объектов 
должна поддерживать новый класс баддет, добавленный соседним отделом. И вы 
снова изменяете одну строку. 

Вы закончили разработку своей программы. Компилируете. Связываете. Готово. 

Отлично! Не кажется ли вам, что в этом сценарии что-то не так? Намного правдопо- 
добнее выглядит следующее развитие событий. Вы приходите с производственного сове- 
щания взмыленный, поскольку вам предстоит выполнить кучу работы. Вы запускаете гло- 
бальный поиск. Удаляете фрагмент. Добавляете фрагмент. Делаете ошибки. Исправляете 
ошибки... В этом и заключается работа программиста, не так ли? Хотя эта книга и не га- 
рантирует вам исполнение первого сценария, она поможет вам пройти несколько шагов в 
этом направлении. Здесь предпринята попытка представить язык С++ в новом качестве — 
языка для разработки архитектуры программного обеспечения. 

Традиционно код представляет собой наиболее детализированный и сложный ас- 
пект программного обеспечения. Исторически, несмотря на существование языков 
разных уровней, предназначенных для поддержки методологий проектирования 
(например, объектной ориентации), между проектом программы и ее кодом лежит 
пропасть. Это обусловлено тем, что в коде должны быть учтены все мельчайшие дета- 
ли реализации и множество других побочных моментов. Цель программы в большин- 
стве случаев скрывается за множеством подробностей. 

В этой книге представлена коллекция пригодных к повторному использованию 
шаблонов, называемых обобщенными компонентами (репегіс сотропепїѕ), а также спо- 
собы их разработки. Обобщенные компоненты предоставляют пользователю хорошо 
известные выгоды, свойственные библиотекам, однако они пригодны для более ши- 
рокого спектра системных архитектур. Приемы кодирования и реализации сконцен- 
трированы на задачах и моментах, традиционно присущих проектированию, которое 

обычно предшествует собственно кодированию программ. Благодаря своему высокому 
уровню абстракции обобщенные компоненты позволяют необычайно выразительно, 
сжато и легко отображать в коде сложные архитектуры. 

В обобщенных компонентах воплощены три ветви программирования: проектиро- 
вание шаблонов, обобщенное программирование и язык С++. Комбинация этих зле- 
ментов позволила достичь высокого уровня готовности кода к повторному использо- 


ванию, условно говоря, как в горизонтальном, так и в вертикальном направлениях. В 
горизонтальном направлении небольшое количество библиотечного кода позволяет 
реализовать огромное — в принципе, бесконечное — количество структур и моделей 
поведения. В вертикальном направлении степень обобщенности этих компонентов 
делает их пригодными для широчайшего круга программ. 

Своим появлением книга обязана проектированию шаблонов, которое позволяет 
создавать мощные средства решения часто встречающихся задач объектно- 
ориентированной разработки программ. Проектирование шаблонов — это тщательно 
отобранные примеры хорошей разработки — рецепты правильных, пригодных к по- 
вторному использованию решений задач, возникающих в различных областях. Основ- 
ной задачей проектирования шаблонов является создание содержательного лексикона 
(зирвезіїме Іехісоп) для воплощаемых разработок. Эти шаблоны описывают задачу, ее 
проверенное временем решение с разными вариантами, а также последствия выбора 
одного из них. Проектирование шаблонов не связано с конкретными языками про- 
граммирования. Следуя определенным шаблонам проектирования и комбинируя их 
друг с другом, компоненты, представленные в этой книге, стремятся охватить как 
можно более широкий круг конкретных задач. 

Обобщенное программирование — это парадигма, в центре которой лежат абстрактные 
типы, узкий набор функциональных требований и алгоритмы реализации, выраженные в 
терминах этих требований. Поскольку алгоритмы сами определяют точную и тесную связь 
с типами, которыми они могут манипулировать, один и тот же алгоритм можно применять 
для работы с широким спектром типов. Для реализации алгоритмов, приведенных в этой 
книге, использованы методы обобщенного программирования, позволяющие достичь ми- 
нимальной специфичности, невероятной лаконичности и эффективности, присущих про- 
граммам, тщательно разработанным вручную. 

В качестве средства реализации в книге используется только язык С++. В этой 
книге вы не найдете кода, реализующего изящные системы оконного интерфейса, 
сложных библиотек для сетевого программирования или Интеллектуальных механиз- 
мов регистрации (оввіпе тесһапіѕтѕ). Вместо этого вы обнаружите массу базовых 
компонентов, которые облегчают решение как всех описанных выше задач, так и 
многих других. Для разработки этих компонентов язык С++ крайне необходим. Ле- 
жащий в его основе механизм управления памятью, реализованный в языке С, гаран- 
тирует быстрое выполнение программ, поддержка полиморфизма позволяет приме- 
нять приемы объектно-ориентированного программирования, а шаблоны допускают 
использование невероятных машин, предназначенных для автоматической генерации 
кода. Шаблоны проходят красной нитью через всю книгу, поскольку они обеспечи- 
вают тесное взаимодействие пользователя и библиотеки. Пользователь библиотеки 
буквально контролирует способ генерации кода, причем этот способ ограничивается 
самой библиотекой. Предназначение библиотеки обобщенных компонентов — позво- 
лять пользователю создавать собственные типы и определять их поведение, а также 
правильно объединять их с другими обобщенными компонентами. Поскольку при 
этом используются статические методы, ошибки, связанные со смешиванием и под- 
гонкой соответствующих фрагментов, обычно обнаруживаются на этапе компиляции. 


Аудитория 


Аудитория, которой предназначена эта книга, состоит из двух частей. К первой ка- 
тегории относятся опытные программисты на С++, желающие овладеть наиболее со- 
временными методами создания библиотек. В книге представлены новые мощные 
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идиомы языка С++, обладающие удивительными возможностями, некоторые из кото- 
рых невозможно было себе представить. Эти идиомы окажут неоценимую помощь 
при создании. библиотек высокого уровня. Для программистов среднего уровня, же- 
лающих повысить свою квалификацию, книга также будет полезной, особенно если 
они проявят определенную настойчивость. Несмотря на то что иногда в книге встре- 
чаются довольно сложные фрагменты кода на С++, они всегда сопровождаются под- 
робным комментарием. 

Вторая категория состоит из постоянно занятых программистов, которым нужно 
сделать дело, не тратя лишнего времени на изучение теории. Они могут пропустить 
наиболее сложные детали реализации и сосредоточить свое внимание на использовании 
предложенной библиотеки. Каждая глава начинается с подробного введения и закан- 
чивается разделом, посвященным часто задаваемым вопросам. Для понимания и ис- 
пользования компонентов эти разделы окажутся весьма полезными. Компоненты 
можно изучать независимо друг от друга. Они очень мощны и тем не менее безопас- 
ны, и, кроме того, их очень легко применять в своих приложениях. 

От читателя требуется хорошее знание языка С++ и желание знать его еще лучше. 
Следует также иметь представление о шаблонах вообше и стандартной библиотеке 
шаблонов (5ТІ. в частности. 

Знание основных шаблонов проектирования (Гамма и др., 1995) желательно, но не 
обязательно. Идиомы и шаблоны, применяемые в книге, детально описаны. Однако 
эта книга посвящена другой теме — в ней не делается попыток максимально обоб- 
щить шаблоны проектирования. Поскольку они рассматриваются с точки зрения 
прагматичного создателя библиотеки, даже читатель, интересующийся в основном 
шаблонами проектирования, найдет для себя много нового, если захочет. 


Библиотека [ок 


В книге описывается реальная библиотека ло, написанная на языке С++. Локи 
(Іокі) — это бог остроумия в скандинавской мифологии, и автор надеется, что ориги- 
нальность и гибкость этой библиотеки соответствует названию. Все элементы библиоте- 
ки находятся в пространстве имен 1оК1. В примерах программ пространство имен не 
указывается, поскольку это увеличило бы размер кода и затемнило его содержание. Биб- 
лиотеку ГоК! можно свободно загрузить с №еБ-страницы Вттр: //ммм. ам1 . сот/сѕепд/ 
0111е5/0-201-70431-5. 

За исключением части, касающейся потоков, библиотека [ок написана на стан- 
дартном языке С++. Увы, это означает, что многие современные компиляторы не 
смогут работать с ней в полном объеме. Я реализовал и протестировал библиотеку 
Гокі с помощью компиляторов Со4е\/агиог Рго 6.0 компании Меїгометк5 и Сотеаи 
С++ 4.2.38 (оба компилятора работали под управлением системы Міпаомѕ). Похоже, 
что компилятор КАЇ С++ также не должен иметь с этой библиотекой никаких про- 
блем. Как только поставщики распространят новые, усовершенствованные версии 
компиляторов, вы сможете эксплуатировать библиотеку ГоК! полностью. 

Код библиотеки ГоК, а также примеры, приведенные в книге, используют попу- 
лярный стандарт кодирования, предложенный Хербом Саттером (Негь ЗиНег. Я уве- 
рен, что вы легко его поймете. Этот стандарт сводится к следующему. 


• Классы, функции и перечислимые типы выглядят так: і іКетһћіѕ. 
А 
• Переменные и перечислимые значения выглядят так: 1ікетћіѕ. 


• Переменные-члены выглядят так: 1іКетНіз . 
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• Шаблонные параметры объявляются с ключевым словом сТа55, если они пред- 
ставляют собой тип, определяемый пользователем (изег-дейпе4 їуре), и с клю- 
чевым словом турепаме, если тип является простым (ргітійує). 


Структура книги 


Книга состоит из двух основных частей: способы программирования и компонен- 
ты. Часть | (главы 1—4) описывает способы программирования на языке С++, ис- 
пользуемые в обобщенном программировании и, в частности, для создания обобщен- 
ных компонентов. Представлено множество особенностей и способов программиро- 
вания на языке С++: проектирование, основанное на анализе поведения, частичная 
специализация шаблонов, списки типов, локальные классы и т.д. Эту часть можно 
читать последовательно, а затем возвращаться к ней за конкретной информацией. 

Часть П организована так же, как и часть [. В ней рассматривается реализация обоб- 
щенных компонентов. Здесь нет искусственных примеров. Все описанные компоненты 
используются в реальных приложениях. Проблемы, ежедневно встающие перед програм- 
мистами на языке С++, например, интеллектуальные указатели, фабрики объектов и 
функторы, обсуждаются глубоко и решаются в общем виде. Реализации, приведенные в 
тексте, ориентируются на основные потребности программистов и предназначены для ре- 
шения фундаментальных задач. Вместо подробного объяснения, что именно делает тот 
или иной фрагмент кода, в книге последовательно применяется следующий подход: снача- 
ла обсуждается задача, а затем выбирается и реализуется метод се решения. 

Глава 1 посвящена классам стратегий — идиомам языка С++, позволяющим соз- 
давать гибкие шаблоны. 

В главе 2 обсуждаются основные способы программирования на языке С++, отно- 
сящиеся к обобшенному программированию. 

Списки типов, представляющие собой мощные структуры для манипуляции с ти- 
пами, реализуются в главе 3. 

В главе 4 описывается важный вспомогательный инструмент — механизм распре- 
деления памяти для небольших объектов (ѕта!1-објесї аПосаїог). 

Обобщенные функторь, использующие шаблон проектирования Соптапа, обсуж- 
даются в главе 5. 

В главе 6 описываются синглтоны. 

Глава 7 посвяшена интеллектуальным указателям. 

В главе 8 описываются обобщенные фабрики объектов. 

Глава 9 посвящена шаблону проектирования АБзтгасЕ Ғасїогу и его реализации. 

В главе 10 в общем виде реализовано несколько вариантов шаблона проектирова- 
ния \1511ог. 

Механизмы мультиметодов (ти Нте!о4 епріпеѕ), представляющие собой решения, 
ориентированные на использование готовых компонентов, реализованы в главе 11. 
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БЛАГОДАРНОСТИ 


Прежде всего хочу поблагодарить моих родителей за их постоянную заботу. 

Следует подчеркнуть, что этой книги, как и большинства моих профессиональных 
успехов, не было бы без Скотта Мейерса. С момента нашей встречи на Всемирном 
конгрессе по С++ (С++ М/огідз Сопргез$$) в 1998 году Скотт постоянно помогал мне. 
Он первым с энтузиазмом поддержал мои ранние идеи. Скотт познакомил меня с 
Джоном Влиссидесом, положив начало нашему сотрудничеству. Он посоветовал Хербу 
Саттеру сделать меня обозревателем журнала “С++ Верогі" и привел в издательство 
А991зоп-\ееу, практически вынудив начать эту книгу. В конце концов Скотт своими 
советами и замечаниями помогал мне все время в процессе работы над книгой, разде- 
ляя со мной творческие муки. 

Выражаю глубокую признательность Джону Влиссилесу, который своими резкими 
замечаниями убедил меня, что мои решения не идеальны, и помог их улучшить. Гла- 
ва 9 — его заслуга. Она появилась в книге благодаря постоянным требованиям Джона 
не останавливаться на достигнутом и искать более удачные решения. 

Благодарю П. Дж. Плагера (Р. Ј. РІаеғег) и Марка Брианда (Магк Вгіапа), вдохно- 
вивших меня писать статьи в журнал “С/С++ Џѕегѕ Лоигпа!” в то время, когда я счи- 
тал обозревателей этого журнала инопланетянами. | 

Я очень признателен моему редактору Дебби Лафферти (ЮеБЫе І аїїегіу) за ее по- 
стоянную поддержку и полезные советы. 

Мои коллеги по компании Веа“ХеѓмогКѕ, особенно Борис Джеркуница (Вопѕ ЛегКипса). 
и Джим Кнаак (Лт КпааК), очень помогли мне, создав атмосферу свободомыслия, сопер- 
ничества и стремления к вершинам мастерства. Я очень благодарен им за это. 

Выражаю свою признательность всем участникам форумов сотр.1п?.с+-+.тодегае4 и 
сотр.54.с++.Изепег. Эти люди помогли мне лучше понять язык С++. 

Я хотел бы выразить свою благодарность рецензентам моей рукописи: Михаилу Анто- 
неску (МШа| АпюпесКи), Бобу Арчеру (Воб Агсһег) (моему самому строгому рецензенту), 
Аллену Бродману (АНеп Вгоадтап), Ионату Бурете (опиё Вигее), Мирель Чирита (Міге] 
Спийа), Стиву Кламагу (5еуе Сіатаєе), Джеймсу Коплину (Латез Сорйеп), Дугу Хазену 
(Роиё Нагеп), Келвину Хенни (Кеїміп Неппеу), Джону Хикину (Јоһп Ніскіп), Говарлу 
Хиннанту (Но\ага Ніппапі), Сорину Джиану (бойп Лапи), Золтану Кормошу (ХоЁап 
Когтоѕ), Джеймсу Кайперу (Јатеѕ Киурег), Лизе Липпинкот (за Шрріпсої), Джонатану 
Лундквисту (опаїнап Іипадџіѕі), Петру Маргиняну (Реїги Магріпеап), Патрику Мак- 
Киллену (Расіск МсКШеп), Флорину Михайлу (Нопп Мінаїа), Сорину Опря (Ѕогіп Оргеа), 
Джону Поттеру (Јоһп Ройег), Адриану Рапитяну (Аййап КВарйеапи), Монике Рапитяну 
(Мопіса Каріїєапи), Брайану Стентону (Впап Ѕіепіоп), Адриану Стефле (Айпап $їіеЙеа), 
Хербу Саттеру (Неф Зийег), Джону Торйо (Јоһп Топо), Флорину Трофину (Еопп Тгойп) и 
Кристи Власяну (Сгіѕіі Маязеапи). Все они внесли свой вклад в улучшение рукописи. Без 
них мне не удалось бы сделать и половины работы. 

Спасибо Грегу Комо (Сгеё Сотеаи) за то, что он предоставил в мое распоряжение 
превосходный компилятор. 

В заключение я хотел бы поблагодарить всю мою семью и друзей за их постоянное 
поощрение и поддержку. | 


Часть | 


МЕТОДЫ 


РАЗРАБОТКА КЛАССОВ 
НА ОСНОВЕ СТРАТЕГИЙ 


В этой главе описываются понятия стратегии (роіїсу) и классов стратегий (роЦсу с!авзе$), 
играющие важную роль в создании библиотек, эффективно обеспечивающих повторное 
использование кода. Библиотека [ою была задумана именно такой. Кратко говоря, 
проектирование, основанное на стратегиях, позволяет создавать класс со сложным 
поведением из множества маленьких классов (называемых стратегиями), каждый из 
которых отвечает только за один функциональный или структурный аспект. Как следует из 
се названия, стратегия устанавливает интерфейс, соответствующий определенному 
свойству. Стратегии можно реализовывать по-разному, поскольку их интерфейсы целиком 
находятся в компетенции программиста. 

Смешивая и подгоняя стратегии друг к другу, можно моделировать огромное коли- 
чество видов поведения, используя небольшой набор элементарных компонентов. 

Стратегии используются во многих главах этой книги. Обобщенный шаблонный 
класс ѕіпд1етопно1аег (глава б) с помошью стратегий управляет длительностью 
функционирования и обеспечивает безопасность работы в многопоточной среде. 
Класс ѕтагтртг (глава 7) почти целиком сконструирован из стратегий. Механизм 
двойной диспетчеризации (4ЧозЫе-415раёсВ епріпе), описанный в главе 11, использует 
стратегии для выбора разных компромиссов. Реализация. обобщенной “абстрактной 
фабрики” (Сатта єї а|., 1995), приведенная в главе 9, применяет стратегию для вы- 
бора метода создания объектов. 

В этой главе описывается предназначение стратегий, рассматриваются детали их 
проектирования и приводятся советы, позволяющие разложить класс на стратегии. 


1.1. Разнообразие методов разработки программного 
обеспечения 


Область проектирования программного обеспечения как никакая другая техниче- 
ская дисциплина демонстрирует большое разнообразие методов: одну и ту же задачу 
можно правильно решить самыми разными способами, причем между правильным и 
неправильным решением лежит бесконечное количество нюансов. Каждый новый 
способ открывает новый мир. При выборе одного из решений возникает множество 
‚ возможных вариантов, начиная с уровня системной архитектуры и заканчивая малей- 
шими деталями кодирования. Таким образом, разработка программных систем заклю- 
чается в выборе решений из гигантского числа вариантов. 


Рассмотрим простейший пример низкоуровневой разработки — интеллектуальные 
указатели (глава 7). Интеллектуальные указатели (ѕтагё ройщег$) представляют собой 
классы, которые могут быть как одно- так и многопоточными. Они могут использо- 
вать различные стратегии владения ресурсами, а также разные компромиссы между 
безопасностью и скоростью. Кроме того, интеллектуальные указатели могут поддер- 
живать или не поддерживать автоматическое преобразование в обычные указатели. 
Все эти свойства можно свободно комбинировать, причем обычно в конкретной об- 
ласти, для которой предназначено программное обеспечение, наилучшим является 
лишь одно решение. || 

‘Разнообразие методов создания программного обеспечения постоянно смущает 
начинающих разработчиков. Перед ними стоит конкретная задача. Что применить для 
ее успешного решения? События? Объекты? Наблюдатели? Обратные вызовы? Вирту- 
альные классы? Шаблоны? Если абстрагироваться от конкретных деталей, разные ре- 
шения окажутся эквивалентными. 

В отличие от новичка, опытный разработчик программного обеспечения знает, что 
работает, а что — нет. Для каждой конкретной задачи существует множество мето- 
дов решения. Они обладают своими преимуществами и недостатками, которые опре- 
деляют, насколько тот или иной метод подходит для решения поставленной задачи. 
Решение, которое казалось вполне приемлемым на бумаге, на практике может ока- 
заться ошибкой. 

Создавать программное обеспечение сложно, поскольку разработчик постоянно 
должен делать выбор. А в программировании, как и в жизни вообще, трудно сделать 
правильный выбор. " 

Опытный разработчик знает, какой выбор ведет к поставленной цели, в то время 
как новичок каждый раз делает шаг в неизвестность. Опытный архитектор программ- 
ного обеспечения напоминает хорошего шахматиста: он.видит на много ходов вперед. 
Для этого нужно долго учиться. Возможно поэтому гениальные программисты бывают 
очень молодыми, в то время как гениальные разработчики программного обеспечения 
обычно находятся в зрелом возрасте. | 

Кроме головоломок, постоянно возникающих перед начинающими разработчика- 
ми, комбинаторная природа архитектурных решений доставляет много хлопот созда- 
телям библиотек. Для того чтобы реализовать библиотеку, пригодную для создания 
программного обеспечения, разработчик должен классифицировать и адаптировать 
множество типичных ситуаций. Библиотеку следует оставить открытой для модифи- 
каций, чтобы прикладной программист мог приспособить ее для своих нужд, создав 
конкретную программу. 

Действительно, как упаковать гибкие, основательно разработанные компоненты в 
библиотеку? Как предоставить пользователю возможность настраивать эти компонен- 
ты? Как преодолеть “проклятие выбора” с помошью кода, имеющего разумные раз- 
меры? Вот каким вопросам посвящена эта глава, да и вся книга в целом. 


1.2. Недостатки универсального интерфейса 


Реализовать все под оболочкой универсального интерфейса — неудачное решение. 
Это объясняется слелующими причинами. 

К основным негативным последствиям такого выбора относятся интеллектуальные 
издержки, огромный размер и неэффективность библиотеки. Гигантские классы очень 
непродуктивны, поскольку на их изучение нужно тратить большие усилия, они слиш- 
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ком велики, а программы, использующие такие классы, работают намного медленнее, 
чем аналогичные программы, разработанные вручную. 

Однако едва ли не самой важной проблемой, связанной с использованием универ- 
сального интерфейса, является потеря безопасности статических типов (айс туре 
заїсту). Одна из основных целей архитектуры любого программного обеспечения — 
воплощение некоторых аксиом “по определению”. Например, нельзя одновременно 
создавать два объекта класса ѕіпд1етоп (глава 6) или объекты непересекающихся се- 
мейств (аАізіоіпі ат Шез) (глава 9). В идеале разработчик должен накладывать боль- 
шинство ограничений еще на этапе компиляции. 

В большом всеобъемлющем интерфейсе очень трудно учесть все подобные ограни- 
чения. Обычно конкретные ограничения семантически соответствуют лишь части ин- 
терфейса. Это ведет к увеличению разрыва между синтаксической и семантической 
правильностью программ, использующих данную библиотеку. 

Рассмотрим, например, аспект реализации объекта класса 51іпд1есоп, связанный с 
безопасностью работы в многопоточной среде. Если библиотека полностью инкапсу- 
лирует потоковые свойства, то пользователь конкретной, непереносимой системы не 
может использовать библиотеку синглтонов. Если эта библиотека предоставляет дос- 
туп к основным незащишенным функциям, возникает опасность, что программист 
разрушит библиотеку, написав код, который будет синтаксически правильным, но се- 
мантически неверным. 

А что, если библиотека будет реализовывать разные проектные решения в виде разных 
классов более скромного размера? Кажлый класс мог бы воплошать конкретное проектное 
решение. При использовании интеллектуальных указателей, например, естественно ожи- 
дать появления многочисленных реализаций: 51іпо1есоптћгеайейѕтагтєрег, ми1єітћгеаа- 
ейѕтагтртг, кеЁСоиптедѕтагтіртг, кеРЕ1пКеЧтагЕРсг и т.п. 

Для этого подхода характерен резкий рост количества разных вариантов проектных 
решений. Четыре упомянутых класса могут привести к появлению новых комбина- 
ций, например, в виде класса 51пд1етћгеадеавеЁсоиптейѕтагтіріг. Преобразование 
типов приведет к еще большему количеству комбинаций, которые в конце концов 
выйдут за рамки возможностей как программиста, так и пользователя библиотеки. 
Очевидно, что идти этим путем не следует. Преодолеть экспоненциальный рост вари- 
антов с помощью грубой силы невозможно. 

Такого рода библиотеки не только требуют для своей разработки и применения ог- 
ромных умственных усилий, но и являются крайне негибкими. Малейшая непредви- 
денная настройка — например, попытка инициализировать конкретным значением 
интеллектуальные указатели, созданные по умолчанию, — приводит все тщательно 
разработанные классы библиотеки в плачевное состояние. 

В процессе разработки программ на них накладываются определенные ограниче- 
ния. Следовательно, библиотеки, ориентированные на разработку программ, должны 
давать пользователю возможность формулировать свои собственные ограничения, а не 
навязывать встроенные. Раз и навсегда законсервированные проектные решения могут 
оказаться так же непригодными для библиотек, ориентированных на разработку про- 
грамм, как, например, константы, явно заданные в обычных программах. Разумеется, 
наборы “наиболее популярных” или “рекомендуемых” готовых решений вполне до- 
пустимы, если программист может изменять их по мере надобности. 

Эти проблемы иллюстрируют неблагоприятную ситуацию, сложившуюся в области 
разработки библиотек. Большого количества низкоуровневых универсальных и спе- 
циализированных библиотек, облегчающих разработку программ, т.е. структур высо- 
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кого уровня, практически нет. Это парадоксальная ситуация, поскольку любое нетри- 
виальное приложение воплощает некие проектные решения. Следовательно, библио- 
теки, ориентированные на создание программ, должны были бы найти применение в 
большинстве приложений. 

Этот пробел попытались заполнить специальные среды разработки (йате\огК$). Одна- 
ко они в основном предназначены для того, чтобы связать приложение с конкретным про- 
ектным решением, а вовсе не для того, чтобы помочь пользователю выбрать и настроить 
свой проект. Если программист стремится реализовать свой. оригинальный проект, он 
должен начинать все “с нуля”, создавая классы, функции и т.п. 


1.3. Опасно ли множественное наследование? 


Рассмотрим класс Тетрогагубесгетагу, производный от классов бесгетагу и Тетро- 
гагу одновременно'. Класс Тетрогагуѕесгетагу обладает свойствами обоих классов, опи- 
сывая как секретаря, так и временно нанятого служащего. Кроме того, он может иметь и 
свои особенности. Это наталкивает на мысль, что множественное наследование может по- 
мочь нам справиться с экспоненциальным ростом количества проектных решений с по- 
мощью малого числа тшательно подобранных базовых классов. В таком случае пользова- 
тель смог бы создать класс для многопоточного интеллектуального указателя, подсчиты- 
вающего количество ссылок (геЁегепсе-соитеЧ зтай ротег), выведя его из некоторого 
класса ВазебтагЕРтг и классов Ми11ітһгеадеа и веРсоиптед. Любой опытный разработ- 
чик классов знает, что этот наивный подход не работает. 

Анализ причин, по которым множественное наследование не позволяет воплощать 
гибкие проектные решения, помогает найти правильный выход. Проблемы заключа- 
ются в следующем. 


1. Механика. Не существует стандартного кода, позволяющего объединить насле- 
дуемые компоненты в одно целое стандартным образом. Единственным инстру- 
ментом, дающим возможность объединить классы ВазебтагфРЪг, Ми1- 
хітіигеадей и КеҒсоиптеа, является языковый механизм, называемый множест- 
венным наследованием (тире іпрегіїапсе). Для объединения базовых классов 
применяется простая суперпозиция и устанавливаются правила доступа к их 
членам. Это совершенно недопустимо и работает лишь в простейших случаях. 
Чаще всего для достижения желаемого эффекта программист вынужден тша- 
тельно настраивать поведение наследуемых классов. 


2. Информация о типах. Базовые классы не имеют достаточно информации о ти- 
пах, чтобы выполнить свою работу. Представим, например, что мы пытаемся 
реализовать глубокое копирование интеллектуального показателя с помощью 
наследования от базового класса реерсору. Какой интерфейс должен иметь 
класс реерсору? Очевидно, что он вынужден создавать объекты, имеющие тип, 
о котором'єму ничего не известно. 


3. Изменение состояния. Различные аспекты поведения, реализованные в базовых 
классах, должны влиять на одно и то же состояние. Это означает, что они долж- 


1 Этот пример создан на основе старого аргумента, который Бьярн Страуструп (Віагп 5ігоцѕ- 
ігар) привел в пользу множественного наследования в первом издании книги “Тһе С++ Рго- 
вгаттіпв І априаве" (см. Страуструп Б. “Язык программирования С++”. — М.: Мир, 1990. — 
Прим. ред.). В то время множественное наследование в языке С++ сще не было реализовано. 
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ны применять виртуальное наследование от базового класса, имеющего задан- 
ное состояние. Это усложняет разработку и делает ее негибкой, поскольку пред- 
полагается, что классы пользователя наследуют свойства от библиотечных клас- 
сов, а не наоборот. 


Комбинаторное по своей природе, множественное наследование само по себе нельзя 
применять для поддержки многовариантных проектных решений. 


1.4. Преимущества шаблонов 


Для имитации комбинаторного поведения хорошо подходят шаблоны, поскольку 
они позволяют генерировать код во время компиляции, основываясь на типах, ука- 
занных пользователем. 

По способу настройки шаблонные классы принципиально отличаются от обычных. 
Если нужно реализовать какой-то специальный вариант, можно специализировать 
(зрес!а!7е) любые функции-члены шаблонного класса, конкретизировав его. Напри- 
мер, если залан шаблон зтагЕРЕГ<Т>, можно специализировать любую функцию-член 
класса Ѕтагтртг<міадет>. Это позволяет хорошо детализировать поведение настраи- 
ваемого шаблона. | 

Более того, для шаблонных классов с несколькими параметрами можно использо- 
вать частичную шаблонную специализацию (как мы увидим в главе 2). Это дает воз- 
можность специализировать только некоторые из аргументов шаблонного класса. На- 
пример, с помощью специализации 


хетрТасе <с1аѕѕ Т, сТа55 и> с1аѕѕ Ѕтагтріг { ... }; 


можно специализировать шаблон ЅмағїРіг<Т, у» для класса міддеї, а также для лю- 
бого другого типа, используя следующую синтаксическую конструкцию: 


тетр1ате <с1455 Ц» с1аѕѕ ЅтагтРтіг<мійдет, и> { ... }; 


Статическая и комбинаторная природа шаблонов делает их очень привлекатель- 
ными для создания фрагментов проектных решений. Однако на пути реализации та- 
кого подхода существует несколько неочевидных препятствий. 


1. Невозможно специализировать структуру. Используя лищь щаблоны, невозмож- 
но специализировать структуру класса (т.е. его данные-члены). Специализиро- 
вать можно только функции. 


2. Специализация функций-членов не масштабируется. Можно специализировать любую 
функцию-член шаблонного класса с одним шаблонным параметром, но невозможно 
специализировать отдельные функции-члены ДЛЯ шаблонов с несколькими шаблон- 
ными параметрами. Проиллюстрируем это утверждение примером. 


хетріасе <с1аѕѕ Т> сТа55 мі адет 


моіа ғип() { ... обобщенная реализация ... } 


// ок: специализация функции-члена класса №1 адет 
и <> міадет<сһаг>: : Рип) 


} «.. Специализированная реализация ... 


тетр1ате <с1аѕѕ т, с1аѕѕ Ц» с1аѕѕ баддет 


моїй гип() { ... обобщенная реализация ... } 
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; 
// Ошибка! частичная специализация функции-члена 
// класса байдеї невозможна! 
Тетр1ате «сТа55 > моїй са4дет<сНаг, и>: : Еип() 


{ ... специализированная реализация ... } 
У; 

3. Автор библиотеки не может задать несколько значений по умолчанию. В лучщем 
случае программист, реализующий шаблонный класс, может задать для каждой 
функции-члена одну реализацию по умолчанию. Шаблонная функция-член не 
может иметь несколько аргументов, заданных по умолчанию. 


Сравним список недостатков множественного наследования со списком недостат- 
ков шаблонов. Интересно, что множественное наследование и шаблоны дополняют 
друг друга. Множественное наследование устроено довольно примитивно; шаблоны, 
наоборот, обладают богатыми возможностями специализации. Множественное насле- 
дование теряет информацию о типах; шаблоны ими изобилуют. Специализация шаб- 
лонов, в отличие от множественного наследования, не масштабируется. В шаблонах 
для функции-члена можно задать только один аргумент по умолчанию и создать неог- 
раниченное количество базовых классов. 

Все это позволяет предположить, что с помошью комбинирования шаблонов и множе- 
ственного наследования можно сконструировать очень гибкий механизм, пригодный для 
создания библиотек, содержащих готовые элементы программного обеспечения. 


1.5. Стратегии и классы стратегий 


Стратегии и классы стратегий позволяют реализовать безопасные, эффективные и 
легко настраиваемые элементы проектных решений. Стратегия (ройсу) определяет 
интерфейс обычного или шаблонного класса. Этот интерфейс состоит из определения 
внутренних типов, функций-членов и переменных-членов. 

Понятие стратегии имеет много общего с характеристиками (‘тай$) (АІехапагеѕси, 
2000а), но отличается тем, что в них меньше внимания уделяется типам и больше — 
поведению. Кроме того, понятие стратегии, предложенное нами, напоминает стра- 
тегии проектирования (Сатта еї а!., 1995), но в отличие от них классы стратегий свя- 
зываются на этапе компиляции. 

Например, определим стратегию для создания объектов. Стратегия Сгеатог опи- 
сывает шаблонный класс типа Т. Этот шаблонный класс должен предоставить функ- 
цию-член с именем Сгеате, не имеющую аргументов и возвращающую указатель на 
объект класса т. Это означает, что каждый вызов функции сгеате должен возвращать 
указатель на новый объект класса Т. Точный режим создания объекта определяется во 
время реализации стратегии. 

Определим несколько классов стратегий, реализующих стратегию Сгеатог. Для этого 
существует три способа. Во-первых, можно использовать оператор пем. Во-вторых, вместо 
оператора пем можно вызвать функцию та11ос (Меуетз, 19985). В-третьих, новые объекты 
можно создавать, клонируя их прототипы. Рассмотрим эти методы. 


тетр1ате <с1аѕ5 т> 
$ТгисЕ ОрмемСгеатог 


зхагіс т* Сгеате() 


гетиги пем Т; 
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} 
}; 


хетрТасе <с1аѕѕ т> 
5сгисс ма11оссгеатог 


з5сасіс ТХ Сгеате() 


моїа? Ббиб = 5сд::таТТос(5ігеої(Т)); 
ЗР (!1Биғ) гебигп 0; 
гетиғп пем(биб т: 
) 
}; 


тетр1ате <с1аѕ5ѕ Т» 
5сгисс Ргототуресгеатог 


РгососуреСгеатогСт* роб) = 0) 
: рРГгототуре_ Сроьј) 
п 


Т* Сгеате() 
гетигп рРгососуре. ? рРготохуре_->СТопе() : 0; 


Т* бетргототуре() { гетигп рРгототуре_; } 

моіа ѕетРгосотуре(т* робі) {рргосотуре_ = робі;) 
ргіуате: 

тх рРгобобуре ; 
; 

Данная стратегия может иметь сколько угодно реализаций. Реализации стратегий 
называются классами стратегий?. Классы стратегий по отдельности не используются. 
Они либо наследуются другими классами, либо содержатся в них. . 

Следует отметить, что, в отличие от классических интерфейсов (коллекций чисто 
виртуальных функций), интерфейсы стратегий не имеют четкого определения. Стра- 
тегии ориентируются на синтаксис, а не сигнатуру. Иными словами, стратегия Сгеа- 
тог определяет, какая синтаксическая структура класса считается правильной, и не 
уточняет, какие именно функции класс должен реализовывать. Например, стратегия 
Сгеасог не указывает, должна ли функция Сгеате быть статичёской или виртуальной. 
Она лишь требует, чтобы шаблонный класс определял функцию-член Сгеате. Кроме 
того, стратегия Сгеатог выражает пожелание (но не требует), чтобы функция Сгеаге 
возвращала указатель на новый объект. Следовательно, вполне допускается, что в от- 
дельных случаях функция-член Сгеасе может возвращать нуль или генерировать ис- 
ключительную ситуацию. 

Для одной стратегии можно реализовать несколько классов. Все они должны соот- 
ветствовать интерфейсу, определенному стратегией. Затем, как мы вскоре убедимся, 
пользователь сам выберет, какой класс стратсгии следует использовать в более круп- 
ных структурах. 

Три класса стратегий, определенных выше, имеют разные реализации и даже слег- 
ка отличающиеся интерфейсы (например, класс РгососуреСгеасог имеет две допол- 
нительные функции — сетРгототуре и $етРгототуре). Однако все они. определяют 


2 Это название немного неточное, поскольку, как мы вскоре убедимся, реализациями стра- 
тегии могут быть и шаблонные классы. 
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функцию с именем Сгеате, возвращающую значение требуемого типа, что соответст- 
вует требованиям стратегии Сгеатог. 

Посмотрим, как можно создать класс, применяющий стратегию Сгеатог. Такой класс 
должен либо содержать три ранее определенных класса, либо наследовать их свойства. 

// Код библиотеки 


тетрТате <с1аѕѕ Сгеатіопро1ісу> 
сТаѕ5 міддетмападег : рибТіс Сгеатіопро1ісу 


}; 

Классы, использующие одну или несколько стратегий, называются главными клас- 
сами? (Бозі сІаѕѕеѕ). В приведенном выше примере класс міддетмападег является 
главным классом, обладающим одной стратегией. Главные классы объединяют струк- 
туры и функциональные возможности своих стратегий в один составной модуль. 

При конкретизации (іп5іапііайоп) шаблона міддеїмМападег клиент передает ему 
искомую стратегию. 

// Код приложения 

Туреде? м19детмападег < Ормеисгеатог<и1адет> > муміддетмдг; 

Проанализируем возникший контекст. Если объекту класса мум1Адетмаг нужно соз- 
дать объект класса міадет, он вызывает функцию Сгеате() из подобъекта стратегии 
ОрмемСгеатог«міддет». Однако выбор стратегии создания объектов находится в компе- 
тенции пользователя класса \19де{Мападег. Этот класс по определению позволяет своим 
пользователям уточнять специфические аспекты своих функциональных возможностей. 

Вот в чем заключается суть проектирования классов на основе стратегий. 


1.5.1. Реализация классов стратегий с помощью шаблонных параметров 


Как и в предыдущем примере, шаблонный аргумент стратегии зачастую излишен. 
Необходимость явно задавать шаблонный аргумент стратегии Ормемсгеатог создает 
неудобство. Обычно главный класс знает заранее или легко может установить шаб- 
лонный аргумент класса стратегии. В рассмотренном выше примере класс міддетмап- 
адег всегда управляет объектами, имеющими тип міддеї, поэтому совершенно из- 
лишне и потенциально. небезопасно требовать, чтобы пользователь снова указывал его 
при конкретизации стратегии Ормемсгеатог. 

В этом случае код библиотеки может использовать шаблонные шаблонные парамет- 
ры (1етр|ае іетріаге рагатеќегѕ) следующим образом. 

// код библиотеки 


тетр1ате <тетрТате <с1аѕѕ Сгеатей> с1аѕѕ СгеатіопрРо1ісу> 
с1аѕ5 міддегМападег : рибТіс СгеатіопРо11 су<міадет> 


}; 
Несмотря на внешний ВИД СИМВОЛ Сгеатеа не относится к определению класса 
м1Адетмападег. Его нельзя использовать внутри класса міадеїМападег — он пред- 


3 Несмотря на то что с технической точки зрения главные классы являются шаблонньми, мы 
будем придерживаться данного выше определения, поскольку и главные классы, и шаблонные 
главные классы представляют собой одно и то же понятие. 
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ставляет собой формальный аргумент стратегии СгеатсіопРо1ісу (а не класса міадет- 
мападег), поэтому его можно просто проигнорировать. 

В коде приложения достаточно задать имя шаблона в конкретизации класса 
м1ддетмападег. 

// Код приложения 

туреде{ міддесмападег«ОрмемСгеатог» Мумі адетмдг; 

Использование шаблонных шаблонных параметров вместе с классами стратегий — 
не просто вопрос удобства. Очень важно, что главный класс имеет доступ к шаблону, 
имея возможность конкретизировать его другим типом. Допустим, что объекту класса 
мі ддесматпадег также нужно создать объект типа сагдеї, используя ту же стратегию 
создания объектов. Тогда соответствующий код может выглядеть следующим образом. 

// код библиотеки 


тетр1ате «СсетрТасе <с1аѕѕ> с1аз5 СгеасіопРОЇісу» 
сТа55 міддетМмападег : риБ1іс СгеатіопРої ісу«мі ддет» 


усій роѕотесћіпо (2 


Саддеїт* рм = сгеатіопРо1і су<саддет»> () . сгеате() ; 


} 

}; 

Дает ли использование стратегий какие-либо преимущества? На первый взгляд 
немного. Все реализации стратегии сгеатог тривиальны. Автор класса міадеїмападег 
мог просто написать код, предназначенный для создания объектов, в виде подстав- 
лясмой функции, не прибегая к шаблону. 

Однако использование стратегий придает классу міддеїмападег необычайную гиб- 
кость. Во-первых, при конкретизации класса мі ддесМападег стратегии можно изменять 
извне так же легко, как и шаблонные аргументы. Во-вторых, программист может задавать 
свои собственные стратегии, характерные для конкретного приложения. Можно использо- 
вать оператор пем, функцию та11ос, прототипы или особые библиотеки управления памя- 
тью, присущие только данной операционной системе. Ситуация выглядит так, будто класс 
міддеєсмападег представляет собой небольшое устройство для автоматической генерации 
кода, а пользователь задает способ, которым он генерирует код. 

Для того чтобы облегчить жизнь разработчикам прикладных программ, автор класса 
мі ддесмападег может определить набор часто применяемых стратегий и указать наиболее 
популярную стратегию в виде значения шаблонного аргумента, заданного по умолчанию. 

тетр1ате <тетр]ате «с1а55» с1аѕ5 Сгеасіопро1ісу = ормемсгеатог> 

с1аѕѕ міддетМападег ... | 

Отметим, что стратегии значительно отличаются от виртуальных функций, которые 
обешают тот же эффект. Обычно программист, реализующий класс, определяет функции 
высокого уровня через элементарные виртуальные функции (ритме міпиа! Гипспоп) и да- 
ет пользователю возможность замешать их поведение. Однако, как показано выше, стра- 
тегии основаны на более подробной информации о типах и статическом связывании. Эти 
два фактора представляют собой важные элементы проектирования, которое насыщено 
правилами, определяющими способ взаимодействия типов до запуска программы на выпол- 
нение и диктующими, что можно делать, а что — нет. Стратегии позволяют генерировать 
проекты, комбинируя варианты, не вникая в подробности их внутреннего устройства (іп а 
{уреза таппег). Кроме того, поскольку связывание главного класса с его стратегиями 
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осуществляется во время компиляции, компактность и эффективность полученного кода 
сравнима с его эквивалентами, разработанными вручную. 

Разумеется, свойства стратегий делают их неудобными для динамического связы- 
вания и бинарных интерфейсов, поэтому, по существу, интерфейсы и стратегии до- 
полняют друг друга, а не конкурируют. 


1.5.2. Реализация классов стратегий с помощью шаблонных 
функций-членов 


Вместо использования шаблонных шаблонных параметров можно применять шаб- 
лонные функции-члены и обычные классы. Это значит, что реализация стратегии 
представляет собой простой класс (в противоположность шаблонному классу), содер- 
жащий один или несколько шаблонных членов. 

Например, можно переопределить стратегию Сгеафог и задать обычный 
(нешаблонный) класс, содержащий шаблонную функцию Сгеахе<т>. Этот класс 
будет выглядеть следующим образом. 


ѕїгисї ОрмемСгеатог 


тетр1ате <с1аѕѕ т> 
ѕсатіс Т* Сгеате() 
{ 


гехигп пем Т; 


}; 

Преимущество такого способа определения и реализации стратегии заключается в 
том, что он хорошо поддерживается старыми компиляторами. С другой стороны, стра- 
тегии, определенные таким образом, часто труднее объяснять, определять, реализовы- 
вать и применять. 


1.6. Расширенные стратегии 


Стратегия Сгеатог описывает только одну функцию-член — Сгеахе. Однако в 
классе Ртототуресгеатог содержится на две функции больше: сехРгототуре и $ет- 
Ргососуре. Проанализируем возникающий при этом контекст. 

Поскольку класс міадеїмападег наследует свой класс стратегии, а функции бефРгото- 
Туре и 5есРгоготуре являются открытыми членами класса РгототуреСгеаїог, эти две 
функции передаются классу мійдеїМападег и непосредственно доступны клиентам. 

Однако класс міадеєсмападег обращается только к функции-члену Сгеате. Это 
все, что ему нужно для обеспечения своих функциональных возможностей. В то же 
время пользователям доступен более богатый интерфейс. 

Пользователь, применяющий стратегию Сгеатог, основанную на прототипах, мо- 
жет написать следуюший код. ; 


Хуредеї м14деемападег<РгототуреСгеатог> 
мум14детмападег; 


мтадет* рРгототуре = ...; 
мум Чдетмападег тдг; 
таг. зетРгототуре Срргототуре) ; 
используем объект тдг 
Если впоследствии пользователь решит применить другую стратегию создания 
объектов, компилятор точно определит точки, в которых используется интерфейс, 
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ориентированный на применение прототипов. Именно это и требуется от хорошо 
продуманного проекта. 

Возникающий контекст очень привлекателен. Клиенты, которым нужны расши- 
ренные стратегии, могут извлекать выгоды из более широких функциональных воз- 
можностей, не изменяя базовых функциональных свойств класса-владельца. Не забы- 
вайте, что пользователи (но не библиотека) определяют, какую стратегию применяет 
класс. В отличие от обычных множественных интерфейсов, стратегии дают пользова- 
телю возможность добавлять новые функциональные возможности главного класса, не 
вдаваясь в подробности его устройства. 


1.7. Деструкторы классов стратегий 


Разрабатывая классы стратегий, следует учитывать одну важную деталь. Чаще всего 
при создании классов, производных от своих стратегий, главный класс использует от- 
крытый интерфейс. По этой причине пользователь может автоматически конвертиро- 
вать главный класс в стратегию, а затем удалить этот указатель с помощью оператора 
деТете. Если в классе стратегии не определен виртуальный деструктор, применение 
оператора деїеїе к указателю на объект этого класса приводит к непредсказуемым 
последствиям.“ 

хуредеї мі адетмМападег<Ргототуресгеатог> 

мум адетмападег; 

Мум'і ддеїмападег ит; 

РгототуреСгеатог<мі дет» рсСгеатог з &мт; // Сомнительно, но можно. 

Че1ете рсСгеатог; // Прекрасно компилируется, 

// но приводит к непредсказуемым последствиям. 

Однако определение виртуального деструктора для стратегии противоречит ее ста- 
тической природе и снижает производительность. Многие стратегии вообще не со- 
держат данньх-членов, определяя, по сути, лищь функциональные возможности. Лю- 
бая виртуальная функция приводит к избыточному размеру объектов данного класса, 
поэтому применения виртуального конструктора следует избегать. 

Решение этой проблемы заключается в следующем. При выводе главного класса из 
классов стратегий следует использовать защищенное или закрытое наследование. Од- 
нако это может ограничить применение расширенных стратегий (раздел 1.6). 

Подобную задачу можно легко и эффективно решить, если потребовать, чтобы 
стратегии применяли невиртуальный защищенный деструктор. 


тетр1ате <с1аѕ5 т> 
ѕїгист ОрмемСгеатог 


5сасіс Т* Сгеате() 


гетигп пем т; 


} 
ргогестей: 
зОрмемСгеатогО {} 
}; 
Поскольку деструктор защищен, объекты стратегий могут уничтожаться только объек- 
тами производных классов, поэтому теперь внешние классы не могут применять опе- 


4 В главе 4 показано, почему это происходит. 
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ратор ЯеЛете к указателям на объекты стратегий. Деструктор не виртуален, поэтому 
дополнительных затрат памяти или замедления работы программы не происходит. 


1.8. Факультативные возможности, предоставляемые 
неполной конкретизацией 


Язык С++ придает стратегиям особую мощь, снабжая их интересным свойством. 
Если функция-член шаблонного класса никогда не используется, она не конкретизи- 
руется — компилятор вообще игнорирует ее, проверяя лишь синтаксические ошибки. 

Это дает главным классам возможность задавать и применять факультативные 
свойства классов стратегий. Например, определим функцию-член 5%мітсһрРготоїуре в 
классе м/і ддетмападег. 

// код библиотеки 


тетрТате <фетрТате «сТа55» сТаз55 СгеатіопРОТісу» 
сТа55 міддетмападег : рибТіс СгеасіопРоТісухміддег» 


мої а 5м1єсПРГОСОГСУре(міддеєя рмемРгососуре) 


СгеаїіопРо1ісу<уіддес>& туРо11су = *1һ15; 
е]ете муРо]1су. сетрРгототуре(); 
туРо 1 1су . ЅетРгототуре (рмемРгототуре) ; 
) 
У; 


Возникающий контекст очень интересен. 


• Если пользователь конкретизирует класс мідеїМападег с помошью класса страте- 
гии Сгеатог, поддерживающей работу с прототипами, можно использовать функ- 
цию 5м/і ЕСИРГОТОХуре. 


• Если пользователь конкретизирует класс мі ддетмападег с помошью класса страте- 
гии Сгеатог, не поддерживающей работу с прототипами, и попытается использо- 
вать функцию 5мітсһРгототуре, во время компиляции возникнет ошибка. 


• Если пользователь конкретизирует класс міддетмападег с помощью класса 
стратегии Сгеаїог, не поддерживающей работу с прототипами, и не пытается 
использовать функцию $\7спрготофуре, программа считается правильной. 


Все сказанное выше означает, что класс мійдеїмападег может использовать фа- 
культативные расширенные интерфейсы, но при этом продолжает правильно работать 
и с интерфейсами, обладающими более бедными возможностями, пока пользователь 
не попытается использовать определенные функции класса мі адетмападег. 

Автор класса м14де{Мападег может определить стратегию Сгеаїог следующим об- 
разом. 


Стратегия Сгеатог определяет шаблонный класс типа Т, содержащий функ- 
цию-член Сгеате. Эта функция должна возвращать указатель на новый объект 
типа т. В реализации можно определить две дополнительные функции- 
члены:т* бефРготофуре() и Ѕетргототуре(т*), характеризующие семантику 


5 В соответствии со стандартом языка С++ строгость синтаксической проверки неиспользуемых 
шаблонньх функций зависит от конкретной реализации. Компилятор не выполняет семантическую 
проверку — например, поиск символов не проволится. 
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получения и установки прототипов, используемых для создания объектов. В 
этом случае класс мідадеємападег содержит функцию-член $м7ЕСИРГО®о- 
+уре(Т* рмемРгососуре), удаляющую текущий прототип и задающую его для 
входного аргумента. 


Вместе с классами стратегий неполная конкретизация обеспечивает замечательную 
свободу при разработке библиотек. Можно реализовать тощие (Іеап) главные классы, спо- 
собные использовать дополнительные свойства и состоящие из минимальных стратегий. 


1.9. Комбинирование классов стратегий 


Наибольшую пользу приносят комбинации стратегий. Обычно хорошо разрабо- 
танный класс использует несколько стратегий для реализации разных аспектов своего 
функционирования. Затем пользователь библиотеки выбирает нужный режим работы, 
комбинируя несколько классов стратегий. 

Например, рассмотрим процесс разработки класса для обобщенного интеллекту- 
ального указателя. (Полная реализация этого класса осуществлена в главе 7.) Допус- 
тим, что нам нужно указать два варианта проектного решения, используя стратегии: 
потоковую модель и проверку перед разыменованием. Затем мы реализуем шаблон- 
ный класс зтагертг, использующий две стратегии. 

тетрТате 

< 

с1аѕѕ Т, 
хетрТасе «сТа55» сТа55 сһескіпдро1ісу, 
тетр1а®е «сТа55» с1аѕѕ тһеааіпдмоае1 

> 

с1а$$ стагерск; 

Класс Ѕ$пагіРіг имеет три шаблонных параметра — тип указателя и две стратегии. 
Внутри этого класса эти две стратегии детально описаны, так что класс ЗтагЕРсг ста- 
новится хорошо продуманной оболочкой, интегрирующей две разные стратегии, а не 
жесткой, законсервированной реализацией. Разрабатывая класс $тагЕРег таким обра- 
зом, можно предоставить пользователю возможность конфигурировать его с помошью 
оператора фуредеР. 

туреде{ Ѕтагерег<м1адес, моСпескіпд, $1п91етпгеаде4> 

мтадетртг; 

В рамках некоторых приложений можно определять и применять несколько клас- 
сов интеллектуальных указателей. 

суредеҒ ѕтатртг<міадес, ЕпҒогсемотми11, 5іпдТетігеадей» 

ЅаҒеміддетртг; 

Две стратегии можно сформулировать следующим образом. 

Стратегия Сһескіпд. Шаблонный класс СһескіпдрРо1ісу<т> должен содержать 
функцию-член Сһеск, которую можно вызывать с параметром типа Т*. Перед разы- 
менованием указателя класс Ѕтагїріг вызывает функцию СһесК, передавая ей объект, 
на который ссылается данный указатель. 

Стратегия Тигеадіпдмоде?. Шаблонный класс тһгеааїпдмоде1 <т> должен содер- 
жать внутренний тип, называемый іосК, конструктор которого получает ссылку Те. 
На протяжении всего существования объекта іоск все операции над объектами типа т 
регистрируются. 
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Например, ниже приведена реализация классов стратегий моспеск1пд и Еп#Ғог- 
семотми11. | 


тетр]ате <с1аѕ5 Т> зтгист МОСПескКіпд 
ѕтатіс моїй сһескСт*) {} 
; 
хепрТаге «сТа55 т> $тгист ЕпРогсемотми11 


сТа55 МИТТРОіпсегЕхсерсіоп : рибТіс 514: :ехсерїіоп ( ... ) 
зсасіс уоіа СһескСт* ріг) 
{ 


1Р (рег) Єгом ми1ТРо1птегЕхсерт1оп(); 


}; 

Подключая разные классы стратегии проверки, можно реализовать различные режимы 
работы объектов. Ниже показано, что можно даже инициализировать объект, на который 
ссылается указатель, значением, заданным по умолчанию, получив ссылку на указатель. 


хетрТасе <с]а$$ Т> $зтгис® Епзигемосмиі 1 
ѕтатіс уоіа сһеск(т*& рег) 
ЗРО (! рег) рег = бехреРаи1хуа]ие(); 
}; 


Класс ѕтагтіртіг использует стратегию СНеск1пд следующим образом. 


тетрТаге 

« 
с1аѕѕ т, 
тетр1аїте <с1аѕѕ> с1аѕѕ СһескіпдрРо1ісу, 
сетр1ате <с1аѕ5> с1аѕѕ Тһгеааіпдмоде] 


> 

с1аѕѕ ЅтагірРЕг 
рчЬ1іс Сһескіпдро11ісу<т>, 
риЬ1іс тһгеааіпдмоде1<ЅмагїіРЕг> 


{ 
т* орегатог-> () 
сурепате Тигеадіпдмодеї«5тагсРіг»::Ццоск диагас*һіѕ) ; 
СпесКіпадРої ісуєт»: :Сһеск(роіпёее_) 
гетигп роїптее ; 
} 
ргімате: 


Т* ро1пхее_; 
; 

Отметим, что оба класса стратегий СһескіпдрРо1ісу и тНгеа41пдмо4е] исполь- 
зуют одни и те же функции. Функционирование оператора Ѕтагїріг: : орегатог-> 
зависит от двух шаблонных аргументов. В этом проявляется сила, присущая комби- 
нированию стратегий. / 

Разложив класс на ортогональнье стратегии, можно обеспечить щирокий спектр 
режимов работь с помощью небольшого по обьему кода. 
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1.10. Настройка структур с помощью классов стратегий 


Одно из ограничений, присущих шаблонам, как было указано в разделе 1.4, состо- 
ит в том, что с помощью шаблонов невозможно уточнить структуру класса — только 
его режим работы. В то же время проектирование, основанное на использовании 
стратегий, позволяет уточнить структуру вполне естественным образом. 

Допустим, что нам нужно создать класс Ѕтапїртг без применения указателей. На- 
пример, на отдельных платформах некоторые указатели могут быть представлены осо- 
бым образом — в виде целого числа, которое передается системной функции, возвра- 
шающей настоящий указатель. Для того чтобы решить эту задачу, можно определить 
доступ к указателю, например, с помощью стратегии $тгистиге. Эта стратегия абст- 
рагирует способ хранения указателя. Следовательно, в этой стратегии нужно указать 
типы с именем РОЇ псегтуре (тип указателя) и кеҒегепсетуре (тип ссылки) 

То, что тип указателя не задан жестко как Т*, представляет собой большое преимуще- 
ство. Например, можно использовать класс ѕтагїрЕг с нестандартными типами указателей 
(такими, как указатели пеаг и баг, применяющиеся на компьютерах, имеющих сегменти- 
рованную архитектуру) или легко реализовать такие остроумные решения, как функции 
ребоге и абтег (Зноизитр, 2000а). Эти возможности чрезвычайно интересны. 

По умолчанию интеллектуальный указатель хранится как простой указатель, снаб- 
женный интерфейсом стратегии $+гистиге.- 


тетр1ате <с1аѕѕ т> 
с1аѕ5 реҒаи1ѕтагїіріг51тогаде 


{ 
руБ11с: 
хуредеї т* Ро1птегтуре; 
туредеї Те АеҒегепсеТуре; 
рготестей: 
Роіптегтуре СетРоіптег() { гетиги рег, } 
умоїд 5есРоіпсег(РОіпсегтуре ріг) { роіптее_ = ріг; } 
ргіуате: 
Роіптегтуре ріг; 
4» 
Фактический способ хранения полностью скрыт за фасадом интерфейса стратегии 
5тгистиге. Теперь класс $тагертг может использовать стратегию хранения указателя 


5хогаде, а не группироваться с типом т“. 
тетр1ате 
< 
сТа55 Т, 
тетр1ате «сТа55» с1аѕ5 сһескро1ісу, 
тетр1ате <с1а55> с1аѕ5 тһгеайіпдмоде1, 
тетр1ате «сТа55» с1аѕ5 Ѕїтогаде = реҒаи1їѕЅтагтРег57огаде 
> 
с1аѕ5 Ѕмагїртг; 


Разумеется, для того, чтобы внедриться в нужную структуру, класс ЅтагїіРїг должен 
либо быть производным от класса Ѕїоғгаде<т>, либо группироваться с объектом типа 
Ѕїогаде<т»>. 


Й 


1.11. Совместимые и несовместимые стратегии 


Допустим, нам нужны две конкретизации класса ѕтагїРІг: Еаѕїміддетртг, указа- 
тель без проверки, и $аРем1АдетРтг, указатель с проверкой перед разыменованием. 
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Возникает интересный вопрос: нужно ли присваивать объекты класса Еа5 СМі 4детртг 
объектам класса заРем1Чдефртг? Следует ли присваивать объекты этих классов дру- 
гим переменным? Если такие преобразования необходимы, как их реализовать? 

Отталкиваясь от той точки зрения, что указатели типа ѕаѓемійдеїртг накладыва- 
ют больше ограничений, чем указатели типа Ғаѕтміаддетртг, естественно допустить 
преобразование типа Ғаѕтміадетртг в тип 5аГемідадетріг. Причина этого заключает- 
ся в том, что язык С++ уже поддерживает неявные преобразования, увеличивающие 
ограничения, например, переменных неконстантных типов — в константные. 

С другой стороны, свободное преобразование объектов класса ЅаҒеміадеїрРіг в 
объекты класса Ғаѕїміадеїрїг опасно, поскольку в приложениях основная масса ко- 
да может использовать указатели типа ЅаҒеміадеїРїг, и только небольшое ядро, для 
которого скорость выполнения является крайне важной, может работать с указателя- 
ми типа Ғаѕїіміадеїрте. Разрешая только явные, контролируемые преобразования в 
тип Раз тм ддесРЕГ, можно свести к минимуму использование указателей этого типа. 

Наилучшим и наиболее масштабируемым способом взаимного преобразования 
стратегий является инициализация и копирование объектов класса зтагЕРЕг страте- 
гия за стратегией (ро1ісу Бу ро|су), как показано ниже. (Для простоты рассмотрена 
только одна стратегия — сһескіпд.) 


тетрТате 
« 
с1аѕѕ Т, 
тетрТаге «сТа55» с1аѕѕ СһескіпдрРо1ісу 
> 
сТа55 ѕтагіРіг : рир1іс сһескіпдрРо11ісу<т> 
{ 
Ттетр1ате 
< 
с1аѕѕ ТІ, 
тетр1ате <с1аѕ5> с1аѕ5 СРІ 
> 
ЅмагтРтеСсопѕт ЅтагїтРг<т1, СР1>& отһег) 
: ројіптее_Сотћег.роіптее ), Сһескіпдро1їсу<т> (оспег) 
Фог і 
}; 


Класс ѕтагєрег реализует шаблонную копию конструктора, получающую другую кон- 
кретизацию класса ЅтагїРтг. Код, выделенный полужирным шрифтом, инициализирует 
компоненты класса ѕмагїіРег компонентами другого класса 5тагЕРЕг<Т1, СРІ», получен- 
ными в виде аргументов. 

Вот как работает этот способ. (Проследим за выполнением кода конструктора.) До- 
пустим, у нас єсть класс Ехтепдаедм'ї ддет, производньй от класса міадет. Если объект 
класса  ЗтагуРТг<и1адет, МоСпескіпд»  проинициализировать объектом класса 
ЅтагіРег<Ехтепдеамі адет, Мосһескіпд>, компилятор попытается проинициализиро- 
вать указатель мі ддес* указателем Ехтепдаедміадеся (что вполне допустимо), а объект 
класса мосһескіпд — объектом класса ЅтагіРТгЕХТепаеа<Ехтепдеамї йде, мосһеск- 
іпд>. Возможно, это выглядит подозрительно, но не забывайте, что класс бтагЕРТг яв- 
ляется производным от своих стратегий, так что, по существу, компилятор может легко 
распознать, что мы инициализируем объект класса Моспеск1пд другим объектом того же 
класса. Таким образом, процесс инициализации выполняется без проблем. 
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Перейдем теперь к более интересной части. Допустим, нам нужно инициали- 
зировать объект класса 5тагоРЕГ«Міддес, ЕпҒогсемотми1 1> объектом класса 
ЅмагіРїг<Ехтепдейиі адет, Мосһескіпд>. Как и раньше, указатель типа Ехтепа- 
ейміддет* без проблем преобразовывается в указатель типа мі адет“. Затем ком- 
пилятор попытается сравнить конструкторы классов ЅтагїРтг<Ехтепдеамі адет, 
мосһесКіпд> и ЕпЁогсемогми1 1. 

Если класс Епбогсемогми11 реализует конструктор, получающий объект мосһеск- 
іпд, то компилятор проверяет этот конструктор. Если класс мосһескіпа реализует 
оператор преобразования в тип ЕпЁогсеми11, вызывается функция, реализующая это 
преобразование. В остальных случаях возникает ошибка компиляции. 

Очевидно, что при реализации преобразований стратегий друг в друга возникает 
удвоенная гибкость: преобразование можно реализовать как с помощью конструктора, 
так и с помошью оператора. 

По сложности это напоминает оператор присваивания, однако, к счастью, ЗиЦег 
(2000) описал очень остроумный способ, позволяющий реализовать оператор при- 
сваивания с помощью конструктора копирования. (Он настолько остроумен, что о 
нем обязательно следует прочитать. Этот способ был применен при реализации класса 
ЅтагіРТг в библиотеке [.оК1.) 

Несмотря на то что преобразования объектов классов мосһескіпо в объекты класса 
ЕПРогсемотми11 и даже наоборот имеют довольно ясный смысл, некоторые преобра- 
зования совершенно бессмысленны. Представьте себе преобразование указателя, под- 
считывающего ссылки, в указатель, поддерживающий другую стратегию владения 
(омпетѕһір ро!ісу), например, уничтожение после копирования (4езігасіїхе сору) напо- 
добие $14: :аито_рфг. Такое преобразование семантически неверно. Определение 
указателя, подсчитывающего ссылки, состоит в следующем: все указатели на один и 
тот же объект считаются известными и отслеживаются с помощью единственного 
счетчика. При попытке применить другую стратегию происходит нарушение инвари- 
анта, гарантирующего правильную работу указателя, подсчитывающего ссылки. 

В заключение заметим, что неявные преобразования, изменяющие стратегию вла- 
дения, применять не следует и обращаться с ними нужно с максимальной осторожно- 
стью. Лучше всего изменять стратегию владения указателем, подсчитывающим ссыл- 
ки, явно вызывая соответствующую функцию. Эта функция будет успешно работать, 
только если счетчик ссылок исходного указателя равен 1. 


1.12. Разложение классов на стратегии 


При проектировании, основанном на применении стратегий, самое трудное — 
правильно разложить функциональные возможности класса на стратегии. Основное 
правило заключается в следующем: нужно идентифицировать и назвать проектные 
решения, определяющие режим работы класса. Все, что можно сделать нескольки- 
ми способами, должно идентифицироваться и передаваться от класса к стратегии. 
Не забудьте: проектные рещения, замурованные в класс, подобны константам, 
“зашитым” в код. 

Рассмотрим, например, класс міддеїмападег. Если внутри класса мі аддетмападег 
создается новый объект класса мійдеї, процесс создания объекта нужно передать 
стратегиям. Если класс міддесмападег хранит коллекцию объектов класса міадеї, 
имеет смысл выразить этот способ хранения в виде стратегии, если при этом какой-то 
специфический механизм хранения не имеет особого приоритета. | 
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В идеале главный класс полностью описывается с помощью отдельных внутренних 
стратегий. Он делегирует все проектные решения и ограничения стратегиям. Такой 
класс представляет собой оболочку коллекции стратегий и только дирижирует стра- 
тегиями, добиваясь нужного режима работы. 

Недостаток обобщенного главного класса, чрезмерно перегруженного стратегиями, 
заключается в слишком большом количестве шаблонных параметров. На практике, 
если количество параметров больше четырех, с классом становится трудно работать. 
Тем не менее они оправдывают свое существование, если главный класс обеспечивает 
сложные и полезные функциональные возможности. 

Определение класса с помощью оператора туре4е{ представляет собой важный 
инструмент, позволяющий использовать классы, основанные на стратегиях. Приме- 
нение этого оператора — не просто вопрос удобства. Он гарантирует упорядоченное 
использование класса и его легкое сопровождение. Например, рассмотрим следующее 
определение типа. 


сурейеҒ $тагтРЕг 


< 
міддеє, 
кеРСоиптед, 
мосһескеа 

> 

м1 адеїртг; 


В программе было бы довольно затруднительно использовать длинную специализа- 
цию класса ѕтагіРїг вместо класса міддетРіг. Однако утомительность программиро- 
вания ничего не значит по сравнению с главными проблемами, заключающимися в 
понимании и сопровождении программы. В процессе проектирования определение 
класса міддеє может измениться — например, может применяться стратегия провер- 
ки, отличающаяся от стратегии мосСһескеа. Очень важно, что класс м1Адетрхг ис- 
пользует вся программа, а не только жестко закодированная конкретизация класса 
Ѕтагтрїг. Это напоминает различие между вызываемыми и подставляемыми (іпіїпе) 
функциями. С технической точки зрения подставляемая функция решает ту же зада- 
чу, однако создать абстракцию на ее основе невозможно. 

Раскладывая класс на стратегии, важно найти ортогональное разложение 
(опһовопа! десотроѕііоп). Возникающие при этом стратегии совершенно не зависят 
друг от друга. Распознать неортогональное разложение очень легко — в нем разные 
стратеғии нуждаются в информации друг о друге. 

Например, представим себе стратегию Аггау в интеллектуальном указателе. Эта 
стратегия очень проста — она диктует, ссылается интеллектуальный указатель на мас- 
сив или нет. Можно определить стратегию Аггау так, чтобы она содержала функцию- 
член Т& ЕТетепсАС(Т" рег, ип5ідпед іптї 1пдех), а также аналогичную версию 
для типа сопѕї т. В стратегиях, не работающих с массивами, функция 
ЕТемептАт просто не определяется, поэтому попытка ее использовать приведет к 
ошибке во время компиляции. Функция Е1етепед*, в соответствии с определением, 
данным в разделе 1.6, представляет собой факультативную расширенную функцио- 
нальную возможность. 

Реализации двух классов, основанных на стратегии Аггау, приведены ниже. 

тетрТате «сТа55 т> 

5ггисі Т5Аггау 


{ 
те ЕТетепсАС(ТХ ріг, ипѕідпеа 1пе іпдех) 
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гетигп рег [іпаех] ; 
сопѕ1 Те ЕТетепсАС(ТХ ріг, ипѕідпеа іпє іпдех) соп5ї 
гетигп рег[іпаех] ; 


о «сТа55 Т> 5сгисі т5мотАГГау {}; 

Проблема заключается в том, что предназначение стратегии Аггау (указать, ссылается 
интеллектуальный указатель на массив или нет) плохо согласованно с другой стратегией — 
разрушением. Уничтожать указатели на объекты можно с помощью оператора деЛете, а 
указатели на массивы, состоящие из объектов, — оператором де1ете(]. 

Две независимые друг от друга стратегии являются ортогональными. На основании 
данного определения можно утверждать, что стратегии Аггау и реѕїгоу не являются 
ортогональными. 

Для того чтобы описать способ работы с величинами, хранящимися в массиве, и 
способ уничтожения объектов в виде отдельных стратегий, необходимо описать их 
взаимодействие. Например, в стратегии Аггау, кроме функций, можно предусмотреть 
булевскую константу и передать ее в стратегию Безтгоу. Это осложняет и несколько 
ограничивает процесс проектирования обеих стратегий. 

Неортогональные стратегии несовершенны, поэтому нужно стараться их избегать. 
Они снижают уровень типовой безопасности во время компиляции и усложняют про- 
цесс разработки как главного класса, так и классов стратегий. 

Если приходится прибегать к неортогональным стратегиям, нужно хотя бы мини- 
мизировать их взаимную зависимость, передавая класс стратегии в качестве аргумента 
шаблонной функции другого класса стратегии. Этот способ компенсирует недостатки, 
связанные с неортогональностью, за счет гибкости, присущей интерфейсам, основан- 
ным на шаблонах. Теневой стороной этого метода остается тот факт, что одна стра- 
тегия должна явно задавать некоторые детали реализации других стратегий. Это сни- 
жает степень инкапсуляции. 


1.13. Резюме 


Проектирование — это выбор. Чаше всего проблема заключается не в том, что за- 
дачу в принципе невозможно решить, а в том, что у нее существует множество спосо- 
бов решения. Необходимо знать, какие из возможных решений удовлетворительно 
решают поставленную задачу. Это вынуждает нас переходить от высших архитектур- 
ных уровней к низшим. Более того, выбранные варианты можно комбинировать, что 
приводит к появлению “проклятия выбора” из большого количества вариантов. 

Для того чтобы преодолеть “проклятие выбора” с помошью кода, имеющего ра- 
зумные размеры, разработчики библиотек, предназначенных для проектирования 
программного обеспечения, должны изобретать и применять специальные способы. 
Изначально эти методы были предназначены для обеспечения гибкости при автома- 
тической генерации кода в сочетании с небольшим количеством элементарных меха- 
низмов (ргітійме деуісеѕ). Сами по себе библиотеки предоставляют огромное количе- 
ство таких механизмов. Более того, они содержат спецификации (зресШсаНопз), на ос- 
нове которых создаются новые механизмы, так что пользователь может создавать их 
самостоятельно. Это существенно влияет на открытость (ореп-епаеа) проектирования, 
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основанного на стратегиях. Эти механизмы называются стратегиями, а их реализа- 
ции, соответственно, называются классами стратегий. 

Механизм стратегии основан на комбинации шаблонов и множественного насле- 
дования. Класс, использующий стратегии (главный класс), представляет собой шаблон 
со многими шаблонными параметрами (часто называемыми шаблонными шаблонными 
параметрами), каждый из которых является стратегией. Главный класс 
“переадресовывает” части функциональных возможностей стратегиям и действует в 
качестве хранилища нескольких согласованных между собой стратегий. 

Классы, построенные на основе стратегий, обладают богатыми возможностями и 
элегантно раскладываются на функциональные свойства. Стратегия может обеспечи- 
вать функциональное свойство, передаваемое главному классу с помощью открытого 
наследования. Более того, главный класс может реализовывать расширенные функ- 
циональные возможности, которые используют факультативные свойства стратегий. 
Если факультативные функциональные возможности не предусмотрены, главный 
класс компилируется успешно при условии, что расширенные функциональные воз- 
можности не используются. 

Мощь стратегий проявляется через их способность смешиваться и настраиваться. 
Класс, основанный на применении стратегий, может: реализовывать различные режи- 
мы работы, комбинируя более простые виды поведения, предусмотренные стратегия- 
ми. Это превращает стратегии в эффективное средство против “проклятия выбора”. 

Используя классы стратегий, можно настраивать не только режим работы, но и 
структуру. Это важное свойство выводит проектирование, основанное на стратегиях, 
за рамки простого генерирования типов, характерного для контейнерных классов. 

Классы, основанные на стратегиях, обеспечивают гибкость преобразований. При 
использовании копирования “стратегия за стратегией” каждая стратегия может распо- 
знавать, к каким еще стратегиям она имеет доступ, или преобразовываться в них с 
помощью соответствующего конструктора преобразования, оператора преобразования 
или обоих одновременно. 

Разбивая классы на стратегии, нужно следовать двум важным принципам. Первый из 
них —- следует локализовать, назвать и изолировать проектные решения в классе. Эта цель 
является предметом компромисса и может достигаться различными путями. Второй прин- 
цип — нужно искать ортогональные стратегии, т.е. стратегии, не нуждающиеся во взаимо- 
действии друг с другом и способные изменяться независимо друг от друга. 
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ПРИЕМЫ ПРОГРАММИРОВАНИЯ 


В этой главе описывается множество приемов программирования на языке С++, 
используемых на протяжении всей книги. Поскольку эти приемы оказываются полез- 
ными в разных ситуациях, они описываются в максимально общем виде, чтобы их 
легко было применить повторно. Таким образом, один и тот же прием может исполь- 
зоваться в разных ситуациях. Некоторые из этих приемов, например, частичная спе- 
циализачия шаблонов, представляют собой особенности языка программирования. 
Другие, например, диагностические утверждения на этапе компиляции (сотріїе-йте 
аз5епіоп5), программируются отдельно. 

В этой главе рассматриваются следующие приемы и инструменты программи- 
рования. - 


е (Статическая проверка диагностических утверждений. 
• Частичная специализация шаблонов. 
» Локальные классы. 


• Отображения между типами и значениями (шаблонные классы Іпї2Туре и 
Туре2туре). 

е Шаблонный класс Ѕе1ест, средство для выбора типа на этапе компиляции на 
основе проверки логического выражения. 


» Распознавание конвертируемости и наследования на этапе компиляции. 
• Класс туретпРо, удобная оболочка для класса 514: :туре_1 по. 


е Класс Тғаіїѕ, коллекция характеристик ({гаѕ), применимых к любому типу в 
языке С++. 


Взятые по отдельности, каждый прием и соответствующий ему код могут выгля- 
деть тривиально. Обычно их размер не превышает 5—10 вполне понятных строк. Од- 
нако эти приемы программирования обладают важной особенностью: они 
“нетерминальны”, т.е. их можно комбинировать друг с другом, генерируя идиомы вы- 
сокого уровня. В совокупности они образуют солидную основу для служебной биб- 
лиотеки, позволяющей создавать мощные архитектурные конструкции. 

Приемы иллюстрируются примерами, а не сухим описанием. Читая другие главы 
книги, вы можете возврашаться к этой главе за справками. 


2.1. Статическая проверка диагностических 
утверждений 


С появлением обобщенного программирования на языке С++ возникла необходи- 
мость в более совершенных средствах статической проверки (и более конкретных со- 
общениях об ошибках). 

Допустим, что вы разрабатываете функцию для безопасного приведения типов (за 
сазИпе). Вам нужно привести один тип к другому, не потеряв при этом информацию, при- 
чем типы большего размера не должны преобразовываться в типы меньшего размера. 

хетрТасе <с1аѕ5 То, с1аѕ5 Ргот» 

то 5аїе геіптегргет саз5є(Егом гом) 


1 
аз55егс(5ігеої(Егот) «з 5іг2еої(То)); 
гехигп геїпсегргет са5 С«То» (гот); 


} 

Эта функция вызывается с помощью точно такой же синтаксической конструкции, 
как и встроенное приведение типов в языке С++. 

їпо і =...; 

сһаг* р = ѕаҒе_геіптегргет_саѕе<сһаг*> (1); 

Шаблонньй аргумент То указывается явно, а компилятор самостоятельно выводит 
шаблонный аргумент Егот, анализируя тип переменной 1. Сравнивая размеры, можно 
убедиться, что тип, к которому выполняется приведение, способен хранить все биты 
величины приводимого типа. Таким образом, указанный выше код либо выполняет 
вроде бы правильное приведение типов!, либо проверяет диагностическое утвержде- 
ние в ходе выполнения программы. 

Очевидно, было бы гораздо удобнее обнаруживать такие ошибки на этапе компиляции. 
Прежде всего, приведение типов может находиться в очень редко используемой ветви 
программы. При переносе приложения на новый компилятор или платформу невозможно 
запомнить все машинно-зависимые части программы, поэтому в приложении могут ос- 
таться скрытые ошибки, которые приведут к ее краху прямо на глазах у вашего заказчика. 

Однако все не так безнадежно. Выражения, подлежащие вычислению, являются 
статическими константами (сотріїе-ійте сопзіапі). Это означает, что их проверку 
можно осуществлять на этапе компиляции, а не в ходе выполнения программы. Идея 
этого подхода заключается в следующем. Компилятору передается языковая конст- 
рукция, являющаяся допустимой, если значение выражения не равно нулю, и недо- 
пустимой в противном случае. Таким образом, получив выражение, значение которого 
равно нулю, компилятор выдаст сообщение об ошибке. 

Простейшее решение задачи статической проверки диагностических утверждений 
(Уап Ноги, 1997) одинаково хорошо работает как в языке С, так и в языке С++, и ос- 
новано на том, что массивы нулевой длины запрещены. 


#АеЁ1пе ЗТАТТС_СНЕСК(ехрг) { сһаг иппатедГ(ехрг) 7 1 : 0]; } 


Теперь напишем следующий фрагмент. 


тетр1ате «сТа55 То, с1аѕ5 Егот> 
то 5аїе геіпсегргес саз5с(кгот Ёгот) 


{ 


1 В большинстве компьютеров, т.е., используя функцию геіптегргес_саѕї, никогда нель- 
зя быть уверенным в успехе. 
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ЗТАТТС_СНЕСК($12ео(Егот) «з 5іхеовб(То)); 
гехигп геїптегргет са5 «То» СЕгот) ; 


уоїд? ѕотеРоїіптег = ...; 

сһаг с = ѕаҒе_геіпїегргеї са5 «сСпаг» (5о0терої піег); 

Если размер системного указателя превышает размер символа, компилятор выдаст со- 
общение, что программа пытается создать массив нулевой длины. 

С этим подходом связана одна проблема — сообщение об ошибке, выдаваемое 
компилятором, малоинформативно. “Невозможно создать массив нулевой длины” со- 
всем не означает, что “Тип сһаг слишком узок для указателя”. Сделать сообщения об 
ошибках настраиваемыми и платформно-независимыми очень трудно. Для сообщений 
об ошибках не существует правил. Все они характерны лишь для данного компилято- 
ра. Например, если ошибка относится к неопределенной переменной, имя этой пере- 
менной в сообщении может не указываться. 

Гораздо лучше положиться на шаблоны, имеющие информативные имена. К сча- 
стью, компилятор обязан указать имя такого шаблона в сообщении об ошибке. 


сепр1ате<Боо1> тгист СопріТетітевггог; 
сетр1ате<> 5сгисі Сотрі1етімеЕггог<ігие> {}; 


ядебіпе $ТАТТС_СНЕСК(ехрг) \ 
(Сотрі1етітеЕггог<(ехрг) != 0» 02) 

Структура СотріетітеЕггог является шаблоном, получающим параметр, не являю- 
щийся типом (булевскую константу). Она определена только для значения {гие этой бу- 
левской константы. Если попытаться конкретизировать шаблон с помощью выражения 
СотріЛетітеЕ ггог<Ға1ѕе>, компилятор выдаст примерно такое сообщение: 
“Неопределенная специализация Сотрі1етітеєггог<Ға1ѕе>”. Это сообщение немного со- 
держательнее предыдущего и говорит о том, что ошибка сделана преднамеренно. 

Разумеется, здесь есть простор для совершенствования. Можно ли настраивать со- 
общения об ошибках? Идея состоит в следующем. Нужно передать дополнительный 
параметр в шаблон $ТАТТС_СНЕСК и каким-то образом сделать так, чтобы он появился 
в сообщении об ошибке. К недостаткам этого приема следует отнести тот факт, что 
настраиваемое сообщение об ошибке должно подчиняться правилам образования 
идентификаторов в языке С++ (не содержать пробелов, не начинаться с цифры и 
т.д.). Это приводит к улучшенной версии шаблона Сотрі1етітеЕггог, показанной 
ниже. Фактически шаблон Сотрі1еТітеЕггог в новом контексте становится малопо- 
нятным. Более осмысленным является шаблон Сотрі1етітеСһескег. 


сетпр1ате<Ьоо1> $тгисЕ Сотрі1етітесһескег; 


Сотрі1етітесһескег С...) ; 


. 


сетр1ате<> °тгист Сотрі1етітесһескег<Ға1ѕе> {}; 
#Ч4е1пе $ТАТТС_СНЕСК(ехрг, тѕ9) \ 


{\ 
с1аѕѕ ЕВВОВ_##т$4 {}; \ 
(моі) 5 ігеої (СотріТетітеспескег«(ехрг) != 0» ((ЕККОК_##т59()22);\ 


Предположим, что 51іғеоЁ(сһаг) < ѕ1ігео#(моіа*). (Стандарт языка не гаранти- 
рует, что это выражение обязательно является истинным.) Посмотрим, что произой- 
дет, если написать следующий фрагмент программы. 


Глава 2. Приемы программирования 47 


тетр1ате <с1аѕѕ То, с1аѕ5 Ёгом> 
то ѕаҒе геіптегргет са5с(Егот Ёгот) 


1 
ЗТАТІС, СНЕСК (512ео#Ғ(Егот) <= 5ігеої(Тто), 
ре5сіпасіоп Туре Тоо Маггомі); 
гетигп геїпсегргетї са5 «То» (Р гот); 
) 


\014* зотеРо1птег = ...; 
сһаг с = зае_ге1птегргет_са$ і <сһаг> (ѕотеРоіпїег); 
После обработки макроса препроцессором код функции заРе_ге1птегргет_сазт 
примет следующий вид. 
сетрТате <с1аѕ5 То, с1аѕ5 Фгот» 
То ѕаҒе_геіптегргет_саѕт(Ғгот Ғгот) 
1 
{ РР 
с1аѕ5 ЕВВОВ_безт1пат1оп_Туре_Тоо_Маггом {}; 
(мої д)5ігеоб( 
СотріТїетіпеСпескег«(5ігеої(Егоп)) <= 5іг2еоР(То))» ( 
ЕКАОВ__реѕтіпатсіоп._ Туре Тоо Маггом (02); 
} 


гехигп геіпсегргет са5 «То» (Ргот); 


Этот код определяет локальный класс (оса! сіа55) ЕАКОВ рез іпасіоп Туре Тоо Маггом, 
имеющий пустое тело. Затем он создает временное значение типа Сом- 
ріТетітеСрескег«5ігеоб(Егот) <= 5іхеої(То))», инициализированное вре- 
менным значением типа ЕККОК_Рреѕїіпаїіоп_Туре Тоо Маггом. В заключение 
функция 5ігеої вычисляет размер возникшей временной переменной. 

А теперь сделаем фокус! Специализация Сотрі1етітеСпескег«їгие» содержит конст- 
руктор, не имеющий аргументов. Это значит, что если выражение, проверяемое на этапе 
компиляции, имеет значение їгие, то полученная в результате программа считается пра- 
вильной, в противном случае возникает ошибка компиляции. Компилятор не может вы- 
полнить преобразование из типа ЕВАОВ Реѕїіпатіоп_Туре_Тоо_Маггом в тип Сот- 
ріТетітесһескег<Ға15ѕе>. Приятнее всего, что теперь компилятор выводит приблизи- 
тельно такое сообщение об ошибке: “Ошибка: невозможно преобразовать тип 
ЕККОК ре5 сіпасіоп Туре Тоо маггом в тип сотрі1етітесћескег<Ға1ѕе>”. 

Есть! 


2.2.Частичная специализация шаблонов 


Частичная специализация шаблонов позволяет специализировать шаблонный 
класс с помощью подмножества его возможных параметров конкретизации. 
Рассмотрим шаблонный класс итадехт. 


Тетр1ате < сТа55 міпаом, с1аѕ5 Сопїго11ег> 
с1а55 міддет 
{ 
обобщенная реализация 
Применим полную явную специализацию шаблона. 


тетрТате <> 
с1аѕ5 М14дет <мода1ріа1од, мусопїго11ег> 
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.. специализированная реализация ... 

}; 

Классы Моаа1ріа1од и мусоптго11ег определяются в прикладной программе. 

Обнаружив определение специализации класса мі дет, при определении объектов 
типа міадес<Моаа1ріа1од, Мусопсго11ег> компилятор будет применять специали- 
зированную, а в остальных случаях — обобщенную реализацию. 

Олнако иногда возникает необходимость специализировать класс міддет для лю- 
бых конкретизаций класса міпфом и отдельной конкретизации класса МусСоптго11ег. 
Вот как выглядит частичная специализация шаблона в этом случае. 


// Частичная специализация шаблонного класса міадеї 
сетрТасе <с1аѕѕ міпаом> 


... частичная специализированная реализация ... 

}; 

Обычно в частичной специализации шаблонного класса указываются лишь неко- 
торые шаблонные аргументы, а остальные остаются обобщенными (вепегіс). Конкре- 
тизируя шаблонный класс в программе, компилятор пытается найти оптимальное со- 
ответствие. Сложный и точный алгоритм поиска соответствий позволяет программи- 
сту каждый раз по-новому осуществлять частичную специализацию. Допустим, что 
шаблонный класс Вистоп получает один шаблонный параметр. Затем, даже если класс 
міадес специализируется для любых конкретизаций класса міпіом и отдельной кон- 
кретизации класса МуСоптєғо11ег, класс міддеє можно и дальше частично специали- 
зировать для всех конкретизаций класса Виєіоп и конкретизации Мусоптго1Тег. 


тетрТафе <с1аѕѕ витопАгд> 
сТа55 міддес«Вистоп«вицтопАгу», МуСопїго11ег> 


$; 4 

Как видим, возможности частичной шаблонной специализации поразительны. 
Конкретизируя шаблон, компилятор выполняет сопоставление с эталоном (раїкегп 
таќсһіпв) существующих частичных и полных специализаций, подыскивая наилучший 
вариант. Это обеспечивает программисту невероятную свободу действий. 

К сожалению, частичную шаблонную специализацию невозможно применить к 
функциям, независимо от того, являются они членами класса или нет. Это несколько 
снижает уровень гибкости и степень детализации программы. 


• Несмотря на то что в шаблонном классе можно выполнять полную шаблонную 
специализацию функций-членов, к ним нельзя применять частичную шаблон- 
ную специализацию. 


• Шаблонные функции из пространства имен (не являющиеся членами какого-либо 
класса) невозможно частично специализировать. Болыше всего на частичную спе- 
циализацию шаблонных функций из пространства имен (патезрасе-{еуе] Іетріаїє 
Ёипсііопѕ) похож процесс их замещения. С практической точки зрения это означает, 
что возможность детальной специализации существует лишь для параметров функ- 
ций, но не для возвращаемых ими значений или используемых внутри нее типов. 


Тетр1а+е <с1аѕѕ Т, с1аѕѕ у> Т Ейп(у орі); // исходный шаблон 
Тетр1ате <с1аѕѕ У» моїд ғип<моіа, о> (Су орі); // Неправильная 

// частичная специализация 
Тетр1ате <с1аѕѕ т> т ғип (міпдом обі); // Правильно (перегрузка) 
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Недостаточная детализация частичной специализации существенно облегчает 
жизнь разработчикам компиляторов, но затрудняет работу программистов. Некоторые 
из инструментов, описанных ниже (например, классы тпт2туре и Туредтуре), специ- 
ально предназначены для преодоления этих ограничений частичной специализации. 

Частичная специализация шаблонов в книге используется очень широко. Фактиче- 
ски все средства для работы со списками типов (глава 3) созданы с ее помощью. 


2.3. Локальные классы 


Локальные классы — это интересное и мало изученное свойство языка С++. Эти 
классы можно определять прямо внутри функций. 


уоїд Еип() 
с1аѕѕ іоса1 


... функции-члены 
определения функций-членов ... 
1 код, использующий локальный класс 

} 

Существует несколько ограничений — в локальных классах нельзя определять ста- 
тические переменные-члены и обращаться к нестатическим локальным переменным. 
Особенно интересно, что локальные классы можно применять внутри шаблонных 
функций. Локальный класс, определенный внутри шаблонной функции, может ис- 
пользовать ее шаблонные параметры. 

Шаблонная функция МаКеАдартег в приведенном ниже коде адаптирует один ин- 
терфейс к другому. Функция МаКеддартег реализует интерфейс на лету с помощью 
локального класса. Локальный класс хранит члены обобщенного типа. 


с1а$5 ІптегҒасе 


рчЬ1їс: 
мігтиа1 моїд ғипО) = 0; 


У; 


тетр1ате <с1а$$ т, с1аѕѕ Р» | 
ТитегРасе* маКеддартег(соп$т Т& обі, соп5т РФ агд) 
{ 


с1аѕ5 іоса1 : рип1іс ІптегҒасе 
риб'іс: 
госа1 (сопѕт Те обі, сопѕт Р& аго) 
: осі (обі), ағд. (ага) {} 
уігтиа1 уоїд ғипО 
обі .са11(ага ); 
рг1уате: 
т обі; 
Р агд_; 


гетигп пем госа1(о6], агд): 
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Легко доказать, что любую идиому, использующую локальный класс, можно реа- 
лизовать с помошью шаблонного класса, определенного вне функции. Иными слова- 
ми, локальные классы для создания идиом непригодны. С другой стороны, локальные 
классы могут упростить реализации и улучшить локальность символов. 

Однако локальные классы обладают уникальным свойством: они являются терми- 
нальными (йпа!). Внешние пользователи не могуг создать производные от них классы, 
скрытые внутри функции. Без локальных классов было бы невозможно добавить не- 
именованное пространство имен в отдельный транслируемый модуль. 

В главе 11 локальные классы используются для создания трамплинных функций. 


2.4. Отображение целочисленных констант в типы 


Простой шаблон, впервые описанный в работе (Айехапагезси, 20006), может ока- 
заться очень полезным для создания многих идиом обобшенного программирования. 


тетр1ате <1пе у» 
5тгисс ІпТ2Туре 


епит { уа1ие = м У; 

}; 

Класс Іпт2Ттуре генерирует различные типы для разных значений передаваемой 
ему целочисленной константы. Это происходит потому, что у разных конкретизаций 
шаблона разные типы. Таким образом, тип конкретизации І1п72Туре<0> отличается от 
типа конкретизации тпе2тТуре<1> и т.д. Кроме того, значение, генерирующее тип, 
“запоминается” членом уа1ие перечисления епит. 

Класс тие2туре применяется, если нужно быстро “типизировать” целочисленную 
константу. С его помошью можно выбирать разные функции в зависимости от ре- 
зультата вычислений, выполняемых на этапе компиляции. Фактически этот класс 
обеспечивает статическую диспетчеризацию (сотрЦИе-Ите аіѕраїсһіпр) константных 
значений целочисленного типа. 

Обычно класс Іпї2Туре используется, когда одновременно выполняются два условия. 


• Нужно вызвать одну из нескольких функций в зависимости от значения стати- 
ческой константы. 


• Эту диспетчеризацию нужно выполнить на этапе компиляции. 


Для осуществления диспетчеризации во время выполнения программы (глт-Ите 
діѕраїсһіпе) можно применять условный оператор 1+-е1зе или оператор ѕмітсһ. Затраты 
машинного времени во многих случаях ничтожно малы. Олнако часто это сделать не уда- 
ется. Оператор 1#-е1ѕе требует, чтобы обе ветки были успешно вычислены, даже если 
проверяемое условие на этапе компиляции уже известно. Непонятно? Читайте дальше. 

Рассмотрим слелуюшую ситуацию. Нам нужно разработать обобшенный контейнер 
мі ?тусоптаїпег. Тип его содержимого задается шаблонньм параметром. 


Тетр1ате <с1аѕѕ Т> с1аѕѕ №іҒтусоптаіпег 


$; 

Допустим, что класс міЁсуСоптаіпег содержит указатели на объекты типа Т. Для дуб- 
лирования объектов, содержащихся в контейнере, нужно вызвать либо конструктор копи- 
рования (для неполиморфных типов), либо виртуальную функцию С1опе() (для поли- 
морфных типов). Эта информация задается в виде булевского шаблонного параметра. 
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сетр1ате <фурепаме т, Ьоо1 1іѕРо1утогрһіс> 
с1аѕ5 №іҒтуСоптаїіпег 


{ 
оід Розомеей1 па () 
{ 
тє рботеб) =. ...; 
1+ (15роТутогрһіс) 
{ 
Т* рмемобі = рѕотеоЬј ->С1опе() ; 
... полиморфньй алгоритм ... 
) 
е1ѕе 
{ 
тх рмемобі = пем Т(*рѕотеоЬј) ; 
... неполиморфньй алгоритм ... 
) 
} 
}; 


Проблема заключается в том, что компилятор не считает этот код правильным. 
Например, поскольку полиморфный алгоритм использует функцию роЬј->С1опе(), 
функция №1РтусСопталпег: : роѕометһіпа не компилируется, если в классе не опреде- 
лена функция-член С1опе(). Правда, уже во время компиляции становится ясно, ка- 
кая из ветвей оператора 1+-е15е выполняется. Однако компилятору эта информация 
ни к чему — он усердно пытается компилировать обе ветви, даже если оптимизатор 
впоследствии исключит тупиковую ветвь кода. Если попытаться вызвать функцию 
РозотетН1па для класса міҒсусоптаіпег<іпс, Гаї5е», компилятор споткнется на 
вызове функции роб) -»СТопе 0 и только презрительно фыркнет в ответ. 

Неполиморфная ветвь кода также может не пройти компиляцию. Ошибка проис- 
ходит, если тип Т является полиморфным, а неполиморфная ветвь кода пытается соз- 
дать новый объект с помощью оператора пем Т("робі). Это может произойти пото- 
му, что тип Т отключает свой конструктор копирования (объявляя его закрытым), как 
это положено прилежному полиморфному классу. 

Было бы прекрасно, если бы компилятор не анализировал тупиковые ветви, но 
увы! Итак, что можно сделать в этой ситуации? 

Получается, что существует большое количество решений, а класс Іпї2Ттуре — са- 
мое очевидное из них. Он может преобразовывать булевскую переменную 1$Ро1утог- 
рһіс в два разных типа в зависимости от ее значения. Затем можно применить класс 
тп&2туре<Ро1утогрИТс> с простой перегрузкой, и готово! 

хепрТасе <турепате т, Ббоо1 іѕРо1утогрћһіс> 

с1аѕ5 Мі Ғтусоптаїіпег 


{ 


ргімаєе: 
моіа розотпеспніпд(тя роб], тпу2туре<егие>) 


Т* рмемобі з робі-»СТопе(О); 
.. полиморфньй алгоритм ... 


моіа роѕотеїһіпд(т* роб], тпї2туре<Ға1ѕе>) 
{ 
т* рмемоЬј = пем Т(*роЬј); 
неполиморфный алгоритм ... 
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рир1їс: А 
моіа роботесніпд(тя робі) 
1 
ро5отпеєсніпу(робі, Іпє2туре<іѕРо1утогрһіс> 0); 


}; 

Класс Іпс2Туре оказывается очень удобным для перевода некоторого значения в 
тип. После преобразования временную переменную этого типа можно передавать пе- 
регруженным функциям, реализующим два требуемых алгоритма. 

Этот прием работает благоларя тому, что компилятор не генерирует шаблонные функ- 
ции, которые никогда не вызываются, — он только проверяет их синтаксис. Таким обра- 
зом, шаблонный код позволяет осуществлять диспетчеризацию во время компиляции. 

В библиотеке №0 класс тпе2туре используется в нескольких местах, особенно в 
главе 11, посвященной мультиметодам. В этой главе шаблонный класс представляет 
собой механизм двойной диспетчеризации, а шаблонный булевский параметр дает 
возможность осуществлять симметричную диспетчеризацию. 


2.5. Отображение одного типа в другой 


В разделе 2.2 указывалось, что частичной специализации шаблонных функций не 
существует. Иногда, однако, хотелось бы иметь такую возможность. Рассмотрим сле- 
дующую функцию. 

тетр1ате «сТа55 Т, сТаз$ у> 


тх Сгеаге(соп5ї И& агд) 
{ 


гесигп пем Т(агд); 


Функция Сгеате создает новый объект, передавая аргумент его конструктору. 

Предположим, что в нашем приложении принято следующее правило. Объект типа 
міддеє содержит недоступный унаследованный код, и для его создания нужны два аргу- 
мента, один из которых представляет собой фиксированное число, скажем, --1. На наш 
собственный класс, производный от класса мійдеї, такие ограничения не накладываются. 

Каким образом можно специализировать функцию Сгеате так, чтобы она обраба- 
тывала объект класса міддет иначе, чем все другие классы? Очевидное решение тако- 
во: нужно создать отдельную функцию Сгеаїемі ідеї. К сожалению, в данный мо- 
мент не существует универсального интерфейса для создания объектов класса м'їадег 
и объектов, производных от этого класса. Это делает функцию Сгеаїе непригодной 
для использования в обобшенном коле (репегіс соде). 

Функцию невозможно специализировать отдельно, т.е. нельзя написать что-то 
вроде следующего кода. 

// неправильный код — не пытайтесь его применять! 


сетр1ате <с1аѕ5 У» 
мі адет“ Сгеате<м1і адет, Ц»(соп5ї 4 агд) 
{ 


гетигп пем міддеї (ага, -1); 


} 


В отсутствие частичной специализации функций существует только одно средст- 
во — перегрузка. Следовательно, для решения поставленной задачи можно передать 
функции Сгеате фиктивный объект (дитту обіесі) типа т и применить перегрузку. 
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тетр1ате <с1аѕ5 т, с1аѕѕ Ц» 
Т* Сгеахе(соп$т 06, агд, т /* фиктивный объект */) 


гетигп пем Т(агд); 


Тетр1ате <с1аѕ5 Ц» 
міддет* Сгеате (сопѕї 04; агд, міддет /* фиктивный объект */) 


гетигп пем міадеї (аго, -1); 


Такое решение может повлечь за собой перегрузку конструктора сколь угодно 
сложного объекта, что также практически бесполезно. Нам необходимо эффективное 
срелство для передачи информации о типе Т в функцию Сгеате. Для этого и нужен 
класс Туре?Туре. Объект этого класса представляет собой идентификатор, несущий 
информацию о типе. Его можно передавать перегружаемым функциям. 

Рассмотрим определение класса Туре2туре. 


тетр1ате <турепате т> 
Ѕ1гисї Туре2туре 
{ 


Туреде# т огідіпаїтуре; 
Класс Туре?Туре предназначен для передачи любого значения, причем каждому от- 
дельному типу соответствует своя конкретизация, что и требовалось доказать. 
Теперь мы можем написать следующий код. 
// Реализация функции Сгеате на основе перегрузки 
// и класса Туре2Туре 
тетр1ате <С1аѕѕ Т, с1аѕ5 Ц» 


Т* Сгеате(сопѕї И& ағд, Туре2Туре<т>) 
{ 


гетигп пем Т(агд); 


Тетр1ате <с1аѕ5 ЦЮ» " 
міддет* Сгеате(сопѕт и& агд, Туре2Туре<міадет>) 
{ 


гетигп пем міддет (аго, -1); 


// Используем функцию Сгеате 

Ѕ1гіпа* рѕїг = Сгеате("Нне110", Туре2Туре<ѕ1гіпд> ()); 

м19дет* ри = Сгеате (100, Туредтурехмі йдет> 0); 
Второй параметр функции Сгеафе предназначен только для выбора подходящей пе- 
регрузки. Теперь эту функцию можно специализировать различными конкретизация- 
ми класса Туре2Туре, которые преобразовываются в разные типы, используемые в 
нашем приложении. 


2.6. Выбор типа 


Иногда в обобщенном коде возникает необходимость выбрать тип в зависимости 
от булевской константы. 

Допустим, что в примере, связанном с классом м№іҒтусоптаїпег, который обсуждался в 
разделе 2.4, в качестве средства для внешнего хранения мы хотим использовать объекты 
класса 514: : местог. Очевидно, полиморфные типы можно хранить только в виде указате- 
лей, а не значений. С другой стороны, мы можем потребовать, чтобы неполиморфные ти- 
пы сохранялись в виде значений, поскольку это более эффективно. 


54 Часть І. Методы 


Рассмотрим шаблонный класс. 


тетрТате <турепате т, боо1 1$Ро1утогрН1 с> 
с1аѕ5 міЁтусоптаіпег 


У; 
Потребуем, чтобы в нем хранились объекты класса местог<Т*> (если значение пере- 
менной і5РОЗутогрііс равно сгие) либо объекты класса уестог<Т> (если значение 
переменной 1іѕРоЛутогрһіс равно Ға15е). По существу, нам нужен оператор 
ТурейеҒ уаТиеТуре, значением которого в зависимости от значения булевской 
переменной і5РОТупогрНіс являются типы Т* или Т 

Для этого можно применить шаблонные классы характеристик (газ) 
(АІехапатеѕси, 2000а). 


хетпрТасе <їурепате т, Боо1 іѕРо]утогрћі с> 
$ЕГисЕ МіРсуСопсаіпегма1иетгаїії5 


хуредеї т» уаТиетуре; 


тетрТате «Турепате т> 
ѕігист мі Ғтусоптаіпегма1иетгаїїѕ<т, Ға1ѕе> 


хуредеї т маїиетуре; 


; 
тетрТате <турепате Тт, Ббоої і5РОТутогрніс» 
с1аѕ5 №і ЁтуСоптаіпег 


Турейе? міфсуСопсаї пегуаТиеТгаї с5«Т, 15$Ро1утогрИ1с> 
тгаї 5; 
Хуредеї турепате Тгаїїѕ : :Уа1иетуре уаТиетуре; 
; 
Это слишком грубое решение задачи. Более того, оно не масштабируется: для каждого 
выбираемого типа приходится определять новый шаблонный класс характеристик. 
Шаблонный класс $е1есе из библиотеки [.оК!1 позволяет выбрать тип прямо на 

месте. Его определение использует частичную шаблонную специализацию. 


тетр1ате <Боо] ад, сурепате Т, турепате у> 
5сгисі 5еТесі 


тхуредеї т Везиїт; 


з 
тетр1ате <турепате т, турепате у> 
ѕ1ігисі Ѕе1есї<Ға15ѕе, Т, Ц» 


Турейе#Ғ у Кеѕи1ї; 
$; 
Если значение переменной #1ая равно їгие, компилятор использует первое 
(обобщенное) определение, и, следовательно, тип Ве5и1 є становится равным Т. Если 
значение переменной #1ад равно Ға1ѕе, вступает в действие специализация, и тип 
Веѕи1т становится равным У. 
Теперь намного легче определить переменную №1 ЁтуСоптаіпег : :МаТиетуре. 


хетрТасе «Ссурепате т, Боо] і5РОТутогрііс» 
сТа55 МівгуСопіаїпег 
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туредеї турепате ѕе1ест<іѕрРо1утогрћіс, ТЯ, Т>: : Вези1 Е 
мацетуре; 


2.7.Распознавание конвертируемости и наследования 
на зтапе компиляции 


При реализации шаблонных функций и классов часто возникает следующий во- 
прос. Даны два произвольных типа Т и 0, о которых ничего не известно. Как опреде- 
лить, наследует ли класс и свойства класса т? Распознавание таких отношений явля- 
ется ключевой проблемой при оптимизации обобщенных библиотек. Если класс реа- 
лизует определенный интерфейс, при работе с обобщенной функцией можно 
положиться на оптимизированный алгоритм. Такое распознавание на этапе компиля- 
ции позволяет избежать динамического приведения типов с помощью оператора ду- 
патіс__саѕ?, на что обычно уходит много машинного времени. 

Распознавание наследования — более общий процесс, чем распознавание конверти- 
руемости. Общая проблема формулируется следующим образом. Как узнать, возможно 
ли автоматическое преобразование произвольного типа Т в произвольный тип 0? 

Можно, например, использовать функцию $12ео. Ее мошь удивительна. Эту функ- 
цию можно применять к любому сколь угодно сложному выражению, и она вернет размер 
его результата, не прибегая к вычислениям в ходе выполнения программы. Это означает, 
что функция 51і2еої распознает перегрузку, конкретизацию шаблонов, правила преобразо- 
вания типов — все, что относится к выражениям в языке С++. Фактически функция 
5ігеої игнорирует само выражение, возвращая лишь размер его результата.? 

Идея, на которой основан механизм распознавания конвертируемости, состоит в 
использовании функции 5ігеої в сочетании с перегруженными функциями. Для 
функции предусматриваются две перегрузки. Одна из них получает тип, который 
должен конвертироваться (в тип Ч), а вторая — что-нибудь другое (неважно, что 
именно). Будем вызывать перегруженную функцию с временной переменной типа Т, 
о котором нужно узнать, конвертируется ли он в тип у. Если будет вызвана функция, 
получающая параметр типа и, значит, тип т конвертируется в тип і. Если будет вы- 
звана нейтральная функция, то тип Т не конвертируется в тип у. Для того чтобы оп- 
ределить, какая функция была вызвана, нужно предусмотреть, чтобы две перегружен- 
ные функции возвращали значения, типы которых имеют разные размеры. Для опре- 
деления этих размеров следует вызвать функцию 5ігеобї. Сами по себе типы нас не 
интересуют — лишь бы они имели разные размеры. 

Итак, сначала создадим два типа с разными размерами. (Очевидно, что типы сһаг 
и 1опд ЗочБЛе имеют разные размеры, однако это не гарантируется стандартом.) 
Безопасная схема выглядит следующим образом. 


2 Есть предложение включить в язык С++ оператор гуреот, т.е. оператор, возврашающий 
тип выражения. С его помошью намного проще писать и понимать шаблонные коды. Язык Спи 
С++ уже реализовал оператор Гуреої в качестве своего расширения. Очевидно, что оператор 
туреої и функция $12ео0+ используют один и тот же код, поскольку в любом случае функция 
512еої должна распознавать тип. 


56 Часть |. Методы 


туредеї спаг ѕта11; 

с1аѕ5 Від { сНаг аитту[2]; У; 
По определению значение 51геої (5та11) равно 1. Размер типа від неизвестен, но он 
определенно больше, чем | (гарантировать можно только это). 

Затем нам понадобятся две перегрузки. Одна из них должна получать параметр ти- 
па у, а возвращать — значение типа ѕта11, например: 


5таї1 Тез є(Ц); 


Как написать функцию, получаюшую “что-нибудь другое”? Шаблон не подходит, 
поскольку он всегда квалифицируется как наилучшее соответствие, а значит, скрывает 
преобразование типов. В данном случае нам нужно “плохое” соответствие, т.е. преоб- 
разование, которое происходит, только если автоматическое преобразование невоз- 
можно. Бегло просмотрев правила преобразования, применяемые к функции, легко 
убедиться, что наихудшим является соответствие, порождаемое эллипсисом (е1ірѕіѕ 
таїсһ), которое находится в самом конце списка. 


від Теѕ1(...); 


(Передача объекта в функцию, описание которой содержит зллипсис, может привести 
к непредсказуемым результатам, но это не имеет значения. На самом деле функция 
не вызывается. Она даже не реализуется. Напомним, что функция 5і2еої не вычис- 
ляет свой аргумент.) 

Теперь нам необходимо применить функцию 5ігеої к вызову функции Теѕї, пе- 
редав ей объект типа Т. 


соп5+ Боої сопмЕХІ5С5 = 5іг2еої (Те5 (ТО)) == 512е0Ё($та]1); 


Вот и все! При вызове функция Тезт получает объект, созданный по умолчанию, — 
ТО, а затем функция 51і2еої вычисляет размер результата этого выражения. Это мо- 
жет быть либо число $12е0#(в19), либо число 51ігеої (5та11), в зависимости от того, 
нашел компилятор преобразование или нет. 

Осталась нерешенной одна небольшая проблема. Если объект класса Т создается 
закрытым конструктором, предусмотренным по умолчанию, то выражение Т() поро- 
ждает ошибку во время компиляции, что разрушает всю нашу стройную конструкцию. 
К счастью, эта проблема имеет простое решение. Достаточно использовать фиктив- 
ную функцию, возврашающую объект класса т. (Еше раз напомним, что чудесная 
функция $12еоЕ на самом деле не вычисляет выражения.) Тогда и компилятор будет 
сыт, и программа цела. 

т макетО; // не реализуется 

соп$т 600] сОпПУЕХЛ$т$ = 5ігеої(Те5:(МАКеТО)) == 5ігеої (ѕта11); 

(Кстати, обратите внимание, как остроумно устроена эта проверка — функции Макет 
и Теѕї не только не имеют никаких параметров, но и не существуют вообще!) 

Итак, все детали этого механизма работают хорошо, и настало время упаковать их 
в шаблонный класс, который скрывает подробности, связанные с процессом вывода 
классов, оставляя на поверхности лишь окончательный результат. 

тетр1ате <с1аѕѕ Т, сТа55 0» 

с1аѕ5 Сопуег$Топ 


{ 
туредеї сһаг $та11; 
сТа55 Від { сһаг аитту[2]; У; 
5хасіс Ѕма11 Тез5є(Ц); 
5тхасіс від Те5с(...); 
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5зсхасіс Т макето; 


рчЬ1їс: 
епит { ехіѕ15 = 
51ғеоҒ(теѕт (Макет ())) == ѕіғео#(ѕта11) У; 
}; 
Теперь можно испытать шаблонный класс Сопуегѕіоп. 
іп маіпО 


и5іпд патеѕрасе 514; 

соці 
<< Сопмег5іоп«доцТе, їпї>::ехіѕ15 << ' 
<< Сопуег5Топ<сНаг, сНаг*>::ех1$т$ << 
<< Сопуеѕгіоп<ѕі е0, местог<іпї> >::ехіѕ1ѕ << ' '; 


} 


Эта небольшая программа выводит на печать строку “1 0 0”. Обратите внимание на 
то, что, хотя класс 514::\уестог реализует конструктор, получающий параметр типа 
5і2е ї, программа возвращает число 0, поскольку это явный конструктор. 

В классе можно реализовать еще одну константу Сопуегѕіоп: :5атетуре, прини- 
мающую значение їгие, если классы т и у представляют собой один и тот же тип. 

тетр1ате <с1аѕ5 Т, с1а55 (> 

сТа55 Сопуег$Топ 


{ 
... как и раньше ... 
епит { затетуре = Ға1ѕе }; 
}; 
Реализуем константу ѕатетуре с помошью частичной специализации шаблонного 
класса Сопуег$ Топ. 


Тетр1ате <с1аѕѕ т> 
с1аѕѕ Сопуегѕіоп<т, т> 


риБ1їс: 
епит ( ехї515 = 1, ѕатеТуре = 1 ); 

}; 

Итак, вернемся к исходной задаче. С помощью класса Сопуег$1оп легко обнару- 
жить наследование. 

ядебіпе ЗИРЕВЗУВСЬА$$ (Т, Ц) \ 

(Сопуегѕіоп<сопѕт Ц*, сопѕт Т*>;:ех1$1$ && \ 
| Сопуегѕіоп<сопѕї Т*, соп$Е \у014*>: :ѕатетуре) ; 

Макрос 5ИРЕВЗИВСІА55 СТ, Ц) вычисляет значение тгие, если класс Ц является 
производным от класса т, или если классы т и у представляют собой один и тот же 
тип. Этот макрос выполняет свою работу, распознавая конвертируемость указателей 
типа сопѕї Ш" в указатели сопѕї т*. Возможны только три случая, в которых указа- 
тели типа сопѕї Ц" неявно преобразовываются в указатели сопѕї Т“. 


1. Классы Т и цу представляют собой один и тот же тип. 
2. Класс т является единственным открытым базовым классом для класса У. 
3. Класс Т представляет собой тип мої. 
Последнее исключается при второй проверке. На практике бывает полезно считать 


первый вариант (классы Т и у представляют собой один и тот же тип) вырожденным 
случаем отношения “является” (“15-а”), поскольку с практической точки зрения лю- 


58 Часть І. Методы 


бой класс часто можно считать собственным суперклассом. Если проверку нужно 
ужесточить, можно написать следующий код. 

#ЧеЁ1пе ЅОРЕКЅОВСІА55 5ТКІСТ(Т, Ц) \ 

(ЗИРЕВЗИВСЬА$5(Т, Ц) && \ 
! (СопмегТоп<соп$т Т, соп$ф Ц»::5атеТуре) 

Зачем в этом фрагменте кода столько модификаторов сопѕ1? Причина состоит в том, 
что проверка не должна завершаться неудачей из-за проблем, связанных с этими модифи- 
каторами. Если шаблонный код применяет модификатор сопѕї лважды (к типу, который 
уже является константным), второй модификатор игнорируется. Короче говоря, модифи- 
катор соп5т в макросе $УРЕВЗУВСЬА$$ применяется в целях безопасности. 

Почему макрос назван ЗИРЕКЗУВСЬА$$, а не ВАЗЕ_ОЕ или ІМНЕВІТ5? По одной 
очень важной причине. Первоначально в библиотеке [0 этот макрос назывался ІМ- 
НЕВТТ$. Однако при использовании выражения ІМНЕВІТЅ (Т, Ц) каждый раз возникал 
вопрос, что именно проверяется: то, что класс Т является производным от класса Ц, 
или наоборот? Очевидно, что выражение Ѕ0РЕВЅОВСІА55(Т, Ц) таких сомнений не 
вызывает, поскольку в его названии первая часть (5УРЕВ) относится к первому пара- 
метру Т, а вторая ($ИВ) — ко второму параметру у. 


2.8. Оболочка вокруг класса їуре іпіо 


В стандарте языка С++ предусмотрен класс $14; : туре_1пФо, позволяющий исследо- 
вать типы объектов в ходе выполнения программы. Обычно класс туре_1пФРо применяется 
в сочетании с оператором туреїа, возврашающим ссылку на объект класса туре_1 по. 


моїд Ғип(Ваѕе* робі) 


// Сравниваєт два объекта типа уре іпіо с типами 
// ®*роБј и регімед, соответственно 
її СсуреїдаСтроб)) == туреід(регімеа) 


ага, на самом-то деле указатель рорј 
ссылается на объект класса Ррегімей ... 


} 


Оператор Суреїфі возвращает ссылку на объект класса туре_1пФо. Кроме операторов 
сравнения орегатог== и орегатог! =, класс туре_1пФо содержит еще две функции. 


е Функция-член пате возвращает текстуальное представление типа в форме пе- 
ременной типа соп5с сНаг*. Стандартного способа преобразовывать имена 
классов в строки нет. Поэтому не следует ожидать, что значением выражения 
хуреї 4 (м1адет) будет строка “мтадет”. Вполне приемлемо (хотя и не слишком 
хорошо), если реализация функции-члена туре_1п+о: : пате возвратит для всех 
типов пустую строку. 

® Функция-член БеҒоге устанавливает между объектами типа туре_1пРо отно- 
шение порядка. Используя эту функцию, можно индексировать объекты класса 
туре_1 по. 

К сожалению, полезные свойства класса туре_1пФо реализованы так, что их трудно 
эксплуатировать. В классе суре іпо не предусмотрены конструктор копирования и опе- 
ратор присваивания, что не позволяет хранить в памяти объекты этого типа. Однако мож- 
но хранить указатели на объекты типа туре іпбо. Объекты, возвращаемые оператором 
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хуреїд, хранятся в статической памяти, поэтому беспокоиться о времени их жизни не 
стоит. Вместо этого следует обеспечить идентичность указателей (роитег 14еп у). 

Стандарт языка С+- не гарантирует, что при каждом вызове, например, оператора 
хуреїаСі пс), возвращается ссылка на один и тот же объект класса туре_1пРо. Следо- 
вательно, сравнить указатели на объекты класса суре іпбо невозможно. Хранить ука- 
затели на объекты этого типа и сравнивать их между собой нужно с помощью функ- 
ции туре_1пРо: : орегатог==, которая применяется к разыменованным указателям. 

При необходимости рассортировать объекты класса суре_1пФо снова нужно сохра- 
нить указатели на них, но на этот раз использовать функцию-член БеРоге. Следова- 
тельно, для того чтобы применить упорядоченные контейнеры из библиотеки шабло- 
нов 5ТІ., нужно написать небольшой функтор (Ѓипсіог) и поработать с указателями. 

Все это довольно неудобно. Для того чтобы преодолеть эти трудности, создадим 
вокруг класса туре_1пФо интерфейсный класс (мтаррег сіаз5), в котором хранится ука- 
затель на объект типа фуре_1 по и предусмотрено следующее. 


• Все функции-члены класса їуре_іпҒо. 


» Семантика значений (открытый конструктор копирования и оператор присваи- 
вания). | 


е Операторы сравнения орегатог< и орегатог==. 


В библиотеке 10! определен интерфейсный класс туретпфо, в котором реализова- 
на описанная выше оболочка класса туре_1пФо. Вот его краткий обзор. 


с1аѕ5 ТуретпРо 


рибі'їс: 
// конструкторы/деструкторы 
туретпРо(); // необходим для контейнеров 
туреїпбо(соп5с 514: : туре_1пРо&) ; 
ТуреІпҒо (соп5т туретпРо&); 
туретиРо& орегатог== (сопѕ1 ТуреІпҒо&) ; 
// Функции сравнения 
Боо1 БеҒоге(сопѕї ТуреІіпҒо&) соп5і; 
сопѕї сһаг* пате() сопѕ+; 

ргімате: 
соп5г $Е4: : Туре _іпҒо* ртиРо_; 

} 


// операторы сравнения 
Боо1 орегатог==(соп$® ТуретпРо&, сопѕї ТуретпРо&); 
Боо1 орегахог!=(соп${ ТуретпҒо&, сопѕс Туреїпбоєб); 
Боо] орегатог<(сопѕт туретпРо&, соп$х Туретп®о&); 
роо] орегаїтог<= (сопѕт ТуретпҒо&, соп5с Туретпбоєб); 
Боо1 орегатог> (сопѕтє ТуретпРо&, сопѕї ТуреІпҒо&) ; 
ђоо1 орегатог>=(сопѕї Туретп®о&, сопѕї ТуретпҒо&) ; 


Благодаря конструктору преобразования (сопуегѕіоп сопѕігисїог), получающему в 
качестве параметра объект класса 5714: : туре _іпҒо, можно непосредственно сравни- 
вать объекты типов ТуреїпТо и $14: : суре_1пРо, как показано ниже. 


уоїд ғип(Ваѕе* робі) 

1 
туреїпбо 1пФо = суреїда(бегіуеа); 
ЇҒ (туреї (гробі) == їпТо) 
{ 


‚.. Указатель рВазе действительно указывает 
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на объект класса регіхеа ... 


Способность копировать и сравнивать между собой объекты класса ТуретпФо важна во 
многих ситуациях. Фабрики клонирования, описанные в главе 8, и механизм двойной 
диспетчеризации, рассмотренный в главе 11, достаточно ярко иллюстрируют этот факт. 


2.9. Классы МиїїТуре и ЕтріуТуре 


В библиотеке ГоК! определены два очень простых типа: Мми11Туре и Епріутуре. Их 
можно использовать для идентификации более широких типов. 
Класс №и11туре служит в качестве нулевого маркера типов (пи тагкег). 


сТа55 №и11Туре (); 


Обычно объекты этого класса не создаются. Его единственное предназначение — обо- 
значить типы, не представляющие интереса. В разделе 2.10 класс №и11туре использу- 
ется в ситуациях, когда тип имеет синтаксический смысл, но не имеет семантическо- 
го. (Например: “На объекты какого типа указывает переменная типа 1п1?”.) Кроме 
того, списки типов, описанные в главе 3, используют класс Ми11Туре в качестве мар- 
кера конца списка и для возврата сообщения “тип не найден”. 

Второй вспомогательный тип — класс ЕтртїуТуре. Как и следовало ожидать, его 
определение имеет следующий вид. 


5єгисі Етргутуре {}; 


Зтот тип можно использовать в качестве базового класса, а также для передачи значе- 
ний типа Етртутуре. Кроме того, его можно применять в шаблонах в качестве типа, 
заданного по умолчанию (“не важно какой”). 


2.10. Характеристики типов 


Характеристики (таП$) — это метод обобщенного программирования, позволяющий 
принимать решения на этапе компиляции программы, основываясь на информации о ти- 
пах, аналогично тому, как в ходе выполнения программы принимаются решения, осно- 
ванные на значениях (А!ехапагезси, 2000а). Предоставляя “дополнительный окольный 
путь”, позволяющий решить многие проблемы, связанные с проектированием программ- 
ного обеспечения, характеристики дают возможность принимать решения, основываясь на 
информации о типах, находясь вне конкретного контекста. Код, полученный в результате, 
становится яснее, читабельнее и легче в эксплуатации. 

Обычно программисты пишут свои собственные характеристические шаблоны и 
классы для обобщенного кода. Однако характеристики можно применять к любым 
типам. Они помогают программисту, создающему обобщенный код, точнее согласо- 
вать шаблонный код с возможностями типа. | , 

Допустим, что мы реализуем алгоритм копирования. 


Тетр1ате <турепате ІпІї, турепате ОиїІї> 
ОитІТ Сору(ІпІї #іг51, ІпІї 1аѕї, ОиїІт геѕи1ї) 


Тог С; Елкгзт != Таѕї; ++#1г5т, ++гези1е) 
хре5ції = *Е1г5т; 
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Теоретически такой алгоритм реализовывать не имеет смысла, поскольку он дублиру- 
ет возможности библиотечной функции 514: : сору. Однако иногда возникает необхо- 
димость специально настроить функцию копирования на определенный тип. 

Предположим, что мы разрабатываем код для многопроцессорной машины, в ко- 
торой предусмотрена очень быстрая элементарная функция вітв1аѕт. Естественно, 
мы хотели бы использовать это преимущество там, где это возможно. 

// прототип функции в19вТазт в заголовочном файле 

// "5ІМО РГітісіме5. В" 

уоіа ВвідвТа5с(соп5Сс усій» 5гс, уоїй? деѕї, $1хе_т Буте5); 
Разумеется, функция відв1аѕт предназначена для копирования только элементарных 
типов и простых старых структур данных. Эту функцию нельзя применять к типам, 
имеющим нетривиальный конструктор копирования. Таким образом, желательно бы- 
ло бы реализовать новую функцию Сору так, чтобы использовать преимущества 
функции відв1аѕт с максимальной выгодой и при копировании объектов более 
сложных типов. При копировании элементарных типов функция Сору “совершенно 
непонятным образом” будет выполняться быстрее. 

Для того чтобы реализовать функцию Сору, нужно выполнить две проверки. 


• Являются ли переменные ІпІї и ОитІт обычными указателями (в отличие от 
более сложных типов итераторов)? 


• Можно ли копировать объекты, на которые ссылаются указатели ІпІС и ОиїІї, 
побитово? 


Если на этапе компиляции мы положительно ответим на оба вопроса, можно применять 
функцию відв1аѕт. В противном случае нужно использовать обобщенный цикл Рог. 

Решить такие проблемы можно с помошью характеристик. В этой главе, в основ- 
ном, используется реализация характеристик из библиотеки Вооѕі С++ (Воо5і). 


2.10.1. Реализация характеристик указателей 


В библиотеке 101 определен шаблонный класс Туретга1т$, в котором собрано 
множество характеристик обобщенных типов. Этот класс специализирует шаблоны, 
содержашиеся в нем, и представляет результаты. 

Реализация характеристик большинства типов основывается на полной или час- 
тичной специализации шаблонов (раздел 2.2). Например, приведенный ниже фраг- 
мент кода определяет, является ли тип Т указателем. 


Тетр1ате <турепате т> 
с1аѕ5 ТуретТгаї (5 


ргіуате: 
Тетр1ате <с1аѕ5 Ц» Ѕїгист Ро1птегТга1т$ 


{ 


епит(геѕи1ї = Ға1ѕе ); 
хуредеї ми11туре Роіптеетуре; 


; 
тетр1ате «сТа55 Ц» $тгист Роіптегтгаітѕ<0*> 


епит { геѕи1їт = тгие }; 
хуредеї У РоїпсеетТуре; 
}; 
руБ11с: 
епит { 15Ро1птег = Роіптегтгаіїѕ<т> : : геѕи1ї }; 
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туредеї РоіптегТгаїє5«Т»::РоїптееТуре Ро1птеетуре; 

$; 

В первом определении вводится шаблонный класс Роіптегтгаіїѕ, который как бы 
говорит: “Класс Т — не указатель”. Напомним, что ранее (в разделе 2.9) в этих ситуа- 
циях применялся класс №и11Туре. 

Во втором определении (выделенном в тексте) вводится частичная специализация 
шаблонного класса РоіптегТгаїї5, соответствующая любому типу указателей. Для 
нулевого указателя, который не ссылается ни на один объект, специализация, выде- 
ленная в тексте фрагмента, квалифицируется как соответствие, более точное, чем 
обобщенный шаблон любого типа указателей. Следовательно, вступает в силу специа- 
лизация для указателей, а переменная гез5иїт принимает значение тгие. Класс 
РОо1птеетуре определяется соответствующим образом. 

Теперь можно понять внутреннее устройство реализации класса 
$14; :местог: :1сегатог — является он простым указателем или представляет собой 
некий сложный тип? 


іпо тали) 
{ 


сопѕт Боої 
1тегт$Ртг = Туретгаіїѕ<местог<іпт> : : 1тегатог> : : і ѕРоіптег; 


соці << "местог«іпі»::їтегагог 15 " << 
іхегі5РоГ ? "Ғаѕт" : "ѕтагі" << "Ми"; 

} 

Аналогично в классе ТуреТгаїс5 реализуется константа і5КеЁегепсе и определя- 
ется тип Вебегепсетуре. Для ссылочного типа т класс КеҒегепсетуре представляет 
собой тип, на который ссылается объект класса т. Если класс Т является обычным ти- 
пом, то класс ВеЁегепсейтТуре совпадает с ним. 

Разпознавание указателей на члены класса (глава 5) немного отличается от опи- 
санного выше. Для этого нужна следуюшая специализация. 


сетр1ате <їтурепате Т> 
с1аѕ5 Туретгаітѕ 


ргімате: 
тетр1ате <с1аѕѕ 0» 5сгисє РТоМТгГаї с5 


епит { геѕи1т = Ға1ѕе У; 


хетрТасе <с1аѕѕ 0, с1аѕѕ МУ» 
5сгисс РТОМТГаї С5«Ц0 М: :*> 


епит { ғеѕи1т = «гие У; 


; 
руБ11с: 
епит { іѕМетрегРоіпсег = РТоМТгаіїѕ<т> : : геѕи1т ); 


}; 


2.10.2. Распознавание основных типов 


Класс ТуреТгаїє5«Т» реализует статическую константу іѕ51ағипдатепса1. По 
значению этой константы можно определить, является класс Т стандартным основ- 
ным типом или нет. К этим типам относится тип моїа и все числовые типы (которые, 
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в свою очередь, подразделяются на типы чисел с плавающей точкой и целочисленные 
типы). В классе ТуреТгаї є5 реализуются константы, показывающие категорию, к ко- 
торой может принадлежать заданный тип. 

Немного забегая вперед, следует сказать, что списки типов (глава 3) позволяют 
легко определять, принадлежит ли тип заданному множеству типов. Пока нам нужно 
знать лишь то, что приведенное ниже выражение (в котором суффикс пп означает ко- 
личество типов, перечисленных в списке) возвращает позицию класса Т в списке, на- 
чиная отсчет от нуля, или число —1, если заданного класса в списке нет. 


ТЕ: :Тпдехо*<Т, ТҮРЕШІЅТ_пп (список типов, разделенных занятыми)> : :уа1ие 


Например, значение выражения 


ті::Іпдехоб«Т, ТУРЕЕТЗТ_4(51дпеЧ сһаг, 5Ногі іпт, 
іпт, Топд іпт)>: :уа1ие 


больше или равно нулю, только если класс т является целочисленным типом со знаком. 
Ниже приведен фрагмент определения класса Туретга1т для основных типов. 


тетр1асе <турепате т> 
с1аѕѕ Туретга1т$ 


... как показано выше 
риБ1іс: 
ТурейеЁ ТҮРЕШІЅТ_4( 
ипѕідпеа сһаг, ип5ідпей ѕһогт іпт, 
ипѕідпеа іп, ипѕідпеа Топд іп) 
упѕідпедІпгѕ ; 
туреде{ ТУРЕШІЗ5Т, 4(5ідпед сһаг, 5погі іпт, іпс, Топд іпт) 
51дпедіпі5; 
ТурейеЁ ТУРЕЕТЬТ_3(Боо1, спаг, мснаг. є) ОтһегІпіѕ; 
туредеї ТУРЕЕТЬТ_3 Соат, дфоцібТе, Топд ЯоиБ1е) ЕПТоат5; 
епит { 155 сдуп5ідпедіІпі = 
ті ::Іпдеховб«т, ипѕідпеаїпт5>: :уа1ие >= 0 У; 
епит ( 155 45 ідпедїпі = 
Ті::Іпдехої«т, 5ідпедІпс5»::маТие >= 0 У; 
епит { і55:фІпседгаї = іѕ5таџопѕідпеаіпг || 155таѕіапеаіпт || 
ті ::Іпдехої«т, отНегтит$>: :уа]ие >= 0 ); 
епит { іѕѕтағ1оат = Ті::Іпдехоб«т, ЕТоаг5»::маТив >= 0 ) 
епит { Т55ЕА4АГТЕЙ = 15570а1Іптедга] || 1557аЕ1оат ); 
епит { ії55сдЕйпдатепта! = ї55сдадгіси || ії55ксдавТоає || 
Сопуег5іоп«Т, \014>: : затетуре ); 


}; 

Использование списков и класса ті: :Тп4ехо* дает возможность быстро получать 
информацию о типах, не прибегая к многократной специализации шаблонов. Если вы 
не можете устоять перед соблазном покопаться в деталях, можете сразу перейти к гла- 
ве 3, но не забудьте вернуться обратно. 

Фактическая реализация процедуры распознавания основных типов намного 
сложнее, что позволяет применять ее для распознавания более широкого спектра 
классов, разрабатываемых производителями программного обеспечения (например, 
11164 или Топд Топд). 


2.10.3. Оптимальные типы параметров 


В шаблонном коде иногда нужно ответить на следующий вопрос. Задан произ- 
вольный тип Т. Какой способ передачи и получения объектов типа т в качестве аргу- 
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ментов функций наиболее эффективен? В общем случае сложные типы эффективнее 
всего передавать по ссылке, а скалярные — по значению. (К скалярным типам отно- 
сятся арифметические типы, описанные ранее, например епит, указатели и указатели 
на члены класса.) Для сложных типов это позволяет избежать ненужных затрат вре- 
мени на вызовы конструкторов и деструкторов, а для скалярных типов — избыточных 
способов доступа к переменным, предоставляемых ссылками. 

Не забудьте, что в языке С++ указатели на ссылки не допускаются. Таким образом, ес- 
ли объект класса Т уже является ссылкой, то новую ссылку на нее создавать не следует. 

Несложный анализ оптимальных типов параметров функции приводит к следую- 
щему алгоритму. Рассмотрим тип параметра с именем Рагатетегтуре. 


Если класс Т — это ссылка на некоторый тип, классы Рагатетегтуре ит 
совпадают (ссылки на ссылки не допускаются). 
В противном случае, 
если класс Т — это скалярный тип (їпс, #1оат и т.п.), то класс 
Рагатетегтуре — это класс Тт (основные типы лучше всего передавать 
по значению), 
иначе класс Рагатетегтуре является типом сопѕ1 Тв (неэлементарные ТИПЫ 
лучше передавать по ссылке). 


Одно из достоинств этого алгоритма состоит в том, что он позволяет избежать ошибки, 
связанной с использованием ссылки на ссылку, которая может возникнуть при совмест- 
ном использовании функций Б1па2 па и мет_Фип из стандартной библиотеки. 

Класс ТуретТгаї 15 легко реализовать с помощью приема, который мы уже приме- 
няли, и определенных выше характеристик ВеРегепсейтуре и 15Ргітміїіме. 


тетрТате «Турепате т> 
с1аѕ5 ТуретТгаї 5 


как и раньше 


риБ1їс: 
туредеї ѕе1ест<іѕ51аАГгіїһ || іѕ$Роіпіег || і5метрегРоїптег, 
т, ВеҒегепсеатуреё& : : веѕи1т 
Рагатетегтуре; 
у; 


К сожалению, эта схема не позволяет передавать по значению параметры перечис- 
лимых типов, поскольку невозможно определить, является заданный тип перечисли- 
мым или нет. 

Класс ТуреТгаї(5::РагатетегТуре используется в шаблонном классе Еипстог, 
определенном в главе 5. 


2.10.4. Удаление квалификаторов 


Имея тип Т, можно легко получить константу, очень похожую на обычную кон- 
станту соп$* т. Однако выполнить обратную операцию (т.е. удалить квалификатор 
соп5 і) намного труднее. Кроме того, иногда возникает необходимость избавиться и 
от квалификатора типа уо1а+1і1е. 

Рассмотрим, например, создание интеллектуального указателя ЅтагєрЕг (глава 7). Если 
бы мы захотели предоставить пользователю возможность создавать интеллектуальные ука- 
затели на константные объекты, например $тагЕРЕг<соп$® м1адет>, пришлось бы моди- 
фицировать указатель на объект класса міддет. В этом случае в классе 5тагЕРЕг следовало 
бы создавать объект класса Мі д4деї на основе константного объекта. 
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Реализовать такой “ликвидатор” достаточно просто. Для этого нужно применить 
частичную шаблонную специализацию. 


хетріасе <+урепате т> 
с1аѕ5 ТуреТгаї 5 


. как и раньше .. 
ргіуате: 
тепр1асе <с1а5$ У» зегисе ИпСопѕт 


хуредеї 0 вези]т; 
тетр1асе «сТа55 М» зегисе ЦпСоп5є«соп5с 0» 
хуредеї у Веѕи1т; 


риб]11с: 
фуреде{ Ипсоп$+<Т>вези]е Мопсопѕ+Туре; 


2.10.5. Применение класса ТуреТгайѕ 


Класс Туретгаї 5 предоставляет много интересных возможностей. Например, с 
помощью описанных выше приемов можно реализовать процедуру Сору, использую- 
щую функцию Вітв1аѕт (проблема, упомянутая в разделе 2.10). Для этого можно 
применить класс Тгаї є5Туре, позволяющий получить информацию о двух итераторах, 
и шаблонный класс Іпє2Туре, осушествляющий диспетчеризацию вызова либо функ- 
ции Вієв1азє, либо классической процедуры копирования. 


епит СоруА1доѕе1естог { Сопзегуатіме, Ғаѕт }; 


// классическая процедура применяется ко всем типам 

тепр1ате <турепате тпте, турепаме Оиетт> 

ОоисІТ СоруІтр1 (ІпІї Т1г5$%, ІпІТ Тазе, ОиїІТ геѕи1т, 
Іпі2Туре<Сопѕегматіме> 


Тог С; Ріг5с |з Тазе; ++Р71г$Ъ, ++гези]е) 
*геѕи1е = *#іг5т; 
гесигп геѕи1т; 
} 
// Быстрая процедура применяется только 
// для указателей на простые данные 
Ттетр1ате <турепаме ІПІС, Сурепате ОСІ» 
ОчЕТе Соруттр1(Стптп Р1г$%, ІпІТ Тазе, Очете гезибі, 


Ти{2туре<га${>) 
{ 
соп5С $12е_т п = Лаѕт-Ғігѕ; 
вієвба5 (Е1г5Е, геѕи1т, п * $12е08(*+1г$%)); 
гетигп гезціє + п; 
} 


хепрТасе <турепате тпте, Сурепате ОисІт> 
Оисіє Сору(ІпІТ Ріг5С, ІпіС 1аѕї, Очете гези]т) 
1 


хуредеї туретгаї є5«ІпІТ7»::Роіпсеетуре ЅгсРоіптее; 
туредеї туретгаітѕ<ОитІТ>::Роіптеетуре Оеѕтроіптее; 
епит { соруА190 = 

туретгаї с5«ІпПІФ»::і5Роїпсег && 

Туретгаітѕ <ОитІт>::15Роїптег && 

Туретгаіїтѕ<5гсРоїптее>: : 155 дЕйпаатепса дб. 
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туретгаї є5«Ре5 РОЇ птее»: ; 155 дРипдатептаї && 

$12еоЁ($гсротитее) == $12еоф(резтро1птее) ? Ғаѕт 
Сопѕегматіме }; 

гетигп Соруттр1 (Е1г5%, Лаѕї, гези]*, Іпї2Туре<соруд1до>); 


} 

Несмотря на то что процедура Сору сама по себе не слишком сложна, в ней есть 
один интересный момент. Перечислимое значение соруд1до позволяет делать выбор 
среди разных реализаций. Логика этого выбора такова: функция ВіїВ1аѕї использу- 
ется, если оба итератора являются указателями, и оба типа, на которые ссылаются 
указатели, являются основными и имеют одинаковый размер. Последнее условие не- 
обычно. Рассмотрим такой фрагмент кода. 

111“ рі = 

іпт* р2 = ..; 

ипѕідпеа іпї* р3 = ...; 

Сору(р1, р2, рз); 

В этом варианте функция Сору вызовет функцию быстрого копирования, как и 
положено, хотя типы источника и адресата отличаются друг от друга. 

Недостаток функции Сору заключается в том, что она не ускоряет то, что можно 
‘было бы ускорить. Например, для простой структуры, характерной для языка С, со- 
держащей лишь данные элементарных типов — так называемой структуры старых 
простых данных (о! ріаіп ааїа ятасиге), или РОО-структуры, стандартом предусмот- 
рено побитовое копирование. Однако функция Сору не распознает простые структуры 
и вызывает медленную процедуру копирования. Здесь, кроме класса туретга1т$, 
нужно снова применить классические характеристики. 


тетрТате <турепате Т> Ѕїгисї ЅиррогтВі тм 5еСору 


епит { гези]* = туретгалтт$<т> : :1551ағипаатепта1 }; 


; 
сетр1ате <їурепате ІпІї, Сурепате Ои?їІї> 
оитІТ Сору(ІпІТ Р1г5е, тптт Лаѕї, Оитіт геѕи1т, 
ІПІ2Туре<1гие>) 


хуредеї ТуреТгаї с5«ІпІіФ»::РоіпсеєеТуре ЅгсРоіптее; 
хуредеї Туретгаіїѕ <ОитІї> : : Роіптеетуре реѕтРоіпїее; 
епит { иѕевітєв1аѕт = 

туретгаітѕ <ІпІТ>::15Роіптег && 

Туретгаїітѕ<Оитт> : :1ѕ5Роіптег && 

Ѕѕиррогтїві мі ѕеСору<5гсРоіптее> : : геѕи1т && 
ѕиррогівіїмі ѕеСору<реѕТРоіпіее> : : геѕи1е && 
512еоҒ(ѕ5ғсРоіпїее) == $12еоҒ(реѕтРоіптее) } 

гетигп СоруІтр1 СҒі гѕт, Тазе, Іпс2Туре<иѕевітв1аѕт>); 


Теперь, чтобы применить функцию вітв1аѕт для РОр-типов, достаточно специа- 
лизировать шаблонный класс ѕиррогтївіїміѕесору и задать в нем значение їгие 


тетр1ате<> зтгист ѕиррогївітиі ѕесору<мусору> 
епит { геѕи1т = тгие }; 


2.10.6. Заключение 
В табл. 2.1 показано все множество характеристик, реализованных в библиотеке 10КІ. 
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2.11. Резюме 


Описанные приемы программирования образуют строительные конструкции для 
создания компонентов, представленных в книге. Большинство этих приемов основано 
на шаблонных кодах. 


Статические диагностические утверждения (раздел 2.1) позволяют библиотекам 
генерировать осмысленные сообщения об ошибках. 


Частичная шаблонная специализация (раздел 2.2) позволяет специализировать 
шаблоны не для фиксированного специального набора параметров, а для се- 
мейства параметров, наиболее соответствующих заданному шаблону. 


Локальные классы (раздел 2.3) допускают интересные возможности, особенно в 
отношении шаблонных функций. 


Отображение целочисленных констант в типы (раздел 2.4) облегчает процесс 
статической диспетчеризации, основанной на числовых значениях (особенно 
булевского типа). 


Отображение между типами (раздел 2.5) позволяет заменить перегрузку функ- 
ций частичной специализацией шаблонов (свойство, которого в стандарте язы- 
ка С++ нет). 


Выбор типов (раздел 2.6) позволяет выбирать типы на основе анализа условных 
выражений. 


Распознавание конвертируемости и наследования на этапе компиляции 
(раздел 2.7) дает возможность получать информацию о том, можно ли преобра- 
зовать два заданных типа друг в друга, являются они псевдонимами одного и 
того же типа или наследуют свойства друг друга. 


Класс ТуретпЁо (раздел 2.8) реализует оболочку для класса 514: : туре_1пРо, 
определяя семантику значений и операции сравнения. 


Классы ми11туре и Емреутуре (раздел 2.9) играют роль структурного нуля в ме- 
тапрограммировании шаблонов. 


Шаблон Туретгаїт5 (раздел 2.10) предоставляет множество характеристик об- 
щего предназначения, которые можно использовать для настройки кода на спе- 
цифическую категорию типов. 


Таблица 2.1. Члены класса ТуреТгаіїѕ<Т> 


Имя Вид Описание 

15РО1птег Булевская константа Принимает значение гие, если класс Т 
является параметром 

Рої псеєтуре Тип Является типом, на который ссылается тип Т, 
если класс Т является указателем, в противном 
случае является типом Ми11туре 

іѕКеҒегепсе Булевская константа Принимает значение гие, если класс Т 
является ссылочным типом 

кеїегепседтуре Тип Если класс Т является ссылочным типом, 
класс КеҒегепсеатуре является типом, на 
который ссылается класс Т. В противном 
случае класс ВеЁегепсеатуре сам является 
классом Т 
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Окончание табл. 2.1 


Имя 


Рагатетегтуре 


15Соп5 
мопСоп5 СТуре 


і5моТасіїе 


МопуоТаті1етуре 
Мопдиа11#1і еатуре 


155 дАупз5 ідпедтпи 


155 д5ідпедтіпи 


155 діпседгаї 


1551ағ1оат 


155 4АГІЄЙИ 


155 «АЕипаатепсаї 


Вид 


Тип 


Булевская константа 
Тип 


Булевская константа 


Тип 
Тип. 


Булевская константа 


Булевская константа 


Булевская константа 


Булевская константа 


Булевская константа 


Булевская константа 


Описание 


Оптимально соответствует параметру 
неизменяемой функции. Может быть либо 
типом Т, либо типом соп5С Т& 


Принимает значение гие, если класс Т 
является константным типом 


Удаляет квалификатор соп$т у типа Т, если 
он у него есть 


Принимает значение гие, если класс Т 
является типом с квалификатором 
уоТасіїе 


Удаляет квалификатор уо1атєі1е у типа Т, 
если он у него есть 


Удаляет квалификаторь сопѕї и моТасіїе 
у типа Т, если они у него есть 


Принимает значение тгие, если класс Т 
является одним из следующих четырех 
беззнаковых типов (ипѕідпей сһаг, 
ипѕідпеа ѕһогт іп, ип5ідпед їпі или 
ипѕідпеа Топд їп) 


Принимает значение тгие, если класс Т 
является одним из следующих четырех 
типов со знаком (ѕідпей сһағ, ѕһогт іп, 
ѕідпеа іп? или Топд іп?) 


Принимает значение їгие, если класс Т 
является обычным целочисленным типом 


Принимает значение гие, если класс Т 
является обычным типом чисел с плавающей 
точкой (ЕТоат, аоиБ1е или Топд аоиб1е) 


Принимает значение гие, если класс Т 
является стандартным арифметическим типом 
(целочисленным или с плаваюшей точкой) 


Принимает значение бие, если класс Т 
является основным типом (арифметическим 
или моїа) 
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Списки типов 


Списки типов представляют собой средство для манипулирования коллекциями 
типов. При этом к типам можно применять все основные операции, предусмотренные 
для обычных списков. 

В некоторых шаблонах проектирования описываются коллекции типов, над которыми 
производятся манипуляции. Эти типы либо связаны между собой отношением наследова- 
ния, либо не зависят друг от друга. Яркими примерами таких шаблонов проектирования 
являются шаблоны АђѕЕгасї Ғастогу и Уіѕітог (Сатта еї а|., 1995). Используя тради- 
ционные методы программирования, можно манипулировать коллекциями типов с помо- 
щью явного повторения. Это приводит к раздуванию кода. Многие люди считают, что ни- 
чего лучше придумать нельзя. Однако списки типов позволяют автоматизировать задачи, 
которые программисты обычно решают с помощью макросов редактора. Списки типов 
придают языку С++ необычайную мощь, позволяя создавать новые, интересные идиомы. 

В этой главе содержится полное описание возможностей списков типов в языке 
С++, а также приводятся многочисленные примеры их применения. Здесь представ- 
лена следующая информация. 


• Концепция списков типов. 
® Способы создания и функционирования списков типов. 
• Методы эффективного манипулирования списками типов. 


. Применениє списков типов и Программирование идиом, поддерживаемых спи- 
сками типов. 


В главах 9-11 показано, как списки типов используются в качестве технологии 
программирования. 


3.1. Зачем нужны списки типов 


Иногда нужно написать один и тот же код для большого количества разных типов, 
и шаблоны тут ничем не могуг помочь. Рассмотрим, например, реализацию шаблона 
АБѕїгасї Расфогу (Сатта єї а|., 1995). Ниже приведено определение виртуальной 
функции для каждого типа из некоторого набора, заданного на этапе проектирования. 


г аѕѕ міддетрастогу 


рир1їс: 
мігсцаї міпдом" Сгеасеміпдом О 0; 
уігіиа1 виттоп” Сгеатевиттоп (>) = 0; 
уіг№иа1 $сго11Ваг* Сгеатеѕсго11ваг() = 0; 


У; 


Если концепцию абстрактной фабрики необходимо обобщить и реализовать в виде 
библиотеки, нужно предоставить пользователю возможность создавать фабрики про- 
извольных наборов типов, а не только типов Міпаом, Виссоп и 5сго11Вваг. Шаблоны 
этой способностью не обладают. 

Хотя на первый взгляд шаблон АБ5 гасі Еастогу не предоставляет широких воз- 
можностей лля абстрагирования и обобщения, некоторые моменты достойны более 


глубокого изучения. 


1. Если вы не можете обобщить основную концепцию, то вряд ли вам удастся обоб- 
щить ее конкретный пример. Это очень важный принцип. Если некая сущность не 
допускает обобщения, то программист вынужден постоянно иметь дело с конкрет- 
ными воплощениями этой сущности. Например, несмотря на то, что базовый класс 
абстрактной фабрики довольно прост, при реализации различных конкретных фаб- 
рик приходится прибегать к многократному повторению одного и того же кода. 


2. Функциями-членами класса \1адетЕастогу невозможно свободно манипулиро- 


вать (см. приведенный выше код). Набор сигнатур виртуальных функций в 
принципе невозможно сделать обобщенным. В качестве примера рассмотрим 


следующий код. 


Тетр1ате <с1аѕ5 Т> 
т* макекеадм'і адет (мі бдесғастогу& Ғастогу) 


{ 
т* рм = Фастогу.сгеахетО; // невозможно!!! 
ри->5етСоТог(КЕО); 
гетигп рм; 

} 


Нужно вызвать функции Сгеатеміпаом, СгеатеВвиттоп или СгеатеѕЅсго11ваг, в 
зависимости от того, что представляет собой класс Т — класс міпаом, вистой 
или 5сго11ваг соответственно. В языке С++ невозможно добиться такой под- 
становки текста. 

. И последнее (по порядку, но не по важности) — библиотеки только выиграли от 
того, что прекратились бесконечные дискуссии о соглашениях, принимаемых 
для записи имен (сгеатемі піом, сгеате, мі пом или Сгеатеміпіом), и тому по- 
добных мелочах. В библиотеках реализован легкий и стандартный способ при- 
нятия подобных решений. Абстрактные фабрики также должны были бы иметь 
такую возможность. 


[2] 


Итак, подытожим наши пожелания. Что касается п. 1, было бы прекрасно, если бы 
мы смогли создавать объекты класса міддетЕастогу, передавая список параметров 
шаблонному классу АБТ$ гастғасїогу. 

туредеї дбѕтгастғастогу<иміпаом, виттоп, ѕсго11ваг> міадетсғастогу; 

Из п. 2 слелует, что нам необходим шаблонный вызов для разных функций вида 
Сгеатеххх, например, Сгеате<міпдом> 0, Сгеате<виссоп> О и т.д. Тогда мы смогли 
бы вызывать эти функции с помощью обобщенного кода. 


хетрТасе <с1аѕ5 т> 
т* Макеведм1 ддет (місддетғастсогу& Ёастогу) 


{ 
тх рм = Еастогу.Сгеате<т> (); // вот это прекрасно! 
ри-»5есСоТог (ВЕР); 
гетигп ри; 

) 
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Однако мы не можем реализовать эти пожелания. Во-первых, оператор туредеР 
для класса міадеїғастогу применить невозможно, поскольку шаблоны не могут 
иметь переменное количество параметров. Во-вторых, шаблонный синтаксис Сге- 
атеххх() недопустим, так как виртуальные функции не могут быть шаблонными. 

Итак, очевидно, что правила языка программирования не позволяют достичь вы- 
сокого уровня абстракции и возможностей повторного использования кода. 

Списки типов позволяют снять эти ограничения и создать не только обобщенные 
абстрактные фабрики, но и реализовать много других шаблонов проектирования. 


3.2. Определение списков типов 


По разным причинам язык С++ иногда позволяет программисту сказать: “Это 
лучшие пять строк кода, которые я когда-либо написал!”. Возможно, это связано с 
семантическим богатством этого языка или с необычностью его свойств. По этой тра- 
диции списки типов выглядят крайне просто. 


тетрТате «сТа55 Т, с1а55 о> 
5їгисс Туре115% 


Турейе# т Һеаа; 
туредеЕ и таї1; 
$; 


патеѕрасе ТІ 


.. алгоритмы работы со списками типов ... 

} 

Все, что относится к спискам типов, за исключением определения самого класса 
Туре1151, пребывает в пространстве имен ть. В свою очередь, пространство имен ТІ. 
находится внутри пространства имен библиотеки [оК1, как и весь код этой библиоте- 
ки. Для того чтобы упростить примеры, в этой главе упоминания пространства имен 
ть пропущены. Читателю следует помнить это, используя заголовочный файл Туре- 
115т.В. (Если вы забудете, компилятор вам напомнит!) 

Класс Туре1151 содержит два типа. Доступ к ним обеспечивается внутренними 
именами неаа и Та11. Вот именно! Нам не нужны списки типов, содержащие три и 
больше элементов, поскольку они у нас уже есть. Например, рассмотрим список ти- 
пов, состоящий из трех вариантов типа сһаг. 

хуредеї туре11ѕт<сһаг, туре1151<ѕідпеа сһаг, ипѕідпеа сһаг> > 

Сһагі1ѕ1; 
(Обратите внимание на раздражающий, но необходимый пробел между двумя грамма- 
тическими лексемами (їоКеп) > в конце строки.) 

Списки типов не содержат никаких значений. Их тела пусты, они не имеют ника- 
кого состояния и не определяют никаких функциональных возможностей. Во время 
выполнения программы списки типов не содержат вообще никақих значений. Их 
единственное предназначение — предоставлять информацию о типах. Следовательно, 
любая обработка списков типов возможна лишь на этапе компиляции, а не в ходе 
выполнения программы. Списки типов не предназначены для создания объектов, хотя 
в их создании нет ничего опасного. Таким образом, термин “список типов” означает 
тип списка, а не его значение. Значения списков типов не представляют никакого ин- 
тереса. На практике применяются только их типы. (В разлеле 3.13.2 показано, как 
списки типов можно использовать для создания коллекций значений.) 
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Здесь используется одна особенность, состоящая в том, что шаблонный параметр 
может иметь любой тип и быть конкретизацией своего собственного шаблона. Это 
старое, хорошо известное свойство шаблонов, которое часто применяется при созда- 
нии таких необычных матриц, как мессог < уессог<аоир1е> >. Поскольку класс 
Туре11ѕ1 имеет два параметра, его всегда можно расширить, заменив один из пара- 
метров другим классом Туре] 15%, и так до бесконечности. 

Однако сушествует одна небольшая проблема. Пока мы можем создавать списки, 
состоящие из нескольких типов, но у нас нет инструмента для описания списков, не 
содержащих никаких типов или содержащих только один тип. Для этого необходим 
нулевой тип списка (пий 1151 туре) и класс Ми11Туре, описанный в главе 2, предназна- 
чен именно для этого. 

Примем соглашение, что каждый список типов должен заканчиваться классом 
ми11туре, служащим маркером конца списка. Это намного удобнее традиционного 
нулевого байта “\0”, который применяется для обозначения конца строк в традици- 
онных функциях языка С. Теперь можно дать определение класса Туре11ѕт, состоя- 
щего лишь из одного элемента. 


// Определение класса ми11туре дано в главе 2 
туреде{ Туреїі5с«хіпс, ми11туре> Опетуреоп1у; 


Определение класса туреї 15, состоящего из трех типов сһаг, принимает следующий вид. 


туреде+ Туреїіз5є«спаг, Туре]1$1<$1дпеа сһаг, 
Туре1іѕт<ипѕідпей сһаг, ми11туре> > > А11сһагтуресѕ; 
Следовательно, мы получили шаблон неограниченного списка типов Туре1і 51, кото- 
рый может содержать любое их количество. 

Посмотрим теперь, как можно манипулировать списками типов. (Как и прежде, 
это относится к типам Туре11$+, а не к объектам типа Туре1іѕт.) Приготовьтесь к 
приключениям. С этого момента мы погружаемся в подземелье языка С++, мир 
странных новых правил — мир программирования на этапе компиляции. 


3.3. Линеаризация создания списков типов 


Сами по себе списки типов слишком напоминают конструкцию из языка Ш$Р, 
поэтому их нелегко использовать. Такие конструкции очень нравятся программистам 
на языке [5Р, но они не очень хорошо согласуются с языком С++ (не говоря уже о 
пробелах между символами <, которые нельзя забывать). Например, вот как выглядит 
список целочисленных типов. 

туредеї Туре11$1<$1дпеа спаг, 

Туреїіз5с«5погі 1пт, | 
Туре11ѕ1<іпє, Туре115+<1опа іпє, МИТТТуре» > > > 
5ідпедіпседгаї5; 
Списки типов были бы превосходной концепцией, но они явно нуждаются в более 
привлекательной упаковке. 

Для того чтобы упростить процедуру создания списков типов, в файле Туре1151.һћ 
из библиотеки Гок определено большое количество макросов, преобразующих рекур- 
сию в простое перечисление, правда, за счет утомительных повторений. Однако это — 
не проблема. Повторение выполняется только один раз, в библиотечном коде. Это по- 
зволяет масштабировать списки типов для большого количества элементов (50). Ти- 
пичный макрос выглядит следующим образом. 
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#аеҒіпе ТҮРЕШІЅТ_1(т1) Туреїізс«ті, №и11туре> 
#аеҒіпе ТҮРЕШІЅТ_2 (Т1, Т2) Туре1151<Т1, ТҮРЕШІЅТ_1(Т2) > 
#деҒіпе ТҮРЕШІЅТ__3 (Т1, Т2, Т3) Туреїі5с«ті, ТУРЕЁТЗТ_2 (Т2, ТЗ) > 
#ае1пе ТҮРЕШ1ЅТ_4 (71, Т2, Т3, Т4) \ 

Туре11$т<т1, туре11$1_3(т2, Т3, 74) 


#аеғі пе ТҮРЕШІЅТ__50(С...) ... 


Каждый макрос использует предыдущий, что позволяет пользователю библиотеки при 
необходимости легко увеличивать верхний предел. 

Теперь можно сформулировать более удобное определение списка целочисленных 
типов 5ідпедІптедгаїз. 

{уреде{ ТУРЕЕТЗТ_4($1дпе4 сһаг, ѕһогі іпі, Топд іп) 

5ідпедфІптедгаї8; 

Линеаризация создания списков типов — всего лишь начало. Манипуляции со списка- 
ми типов все еще неудобны. Например, доступ к последнему элементу списка 5ідпедтп- 
хедгаї вынуждает использовать конструкцию 5ідпедІпіедгаїз::таї1::Таї1::Неай. Не 
вполне понятно, как мы сможем манипулировать списками типов в обобщенном виле. 
Итак, пришло время определить основные операции над списками типов в терминах эле- 
ментарных операций над списками значений. 


3.4. Вычисление длины списка 


Рассмотрим простую операцию. Задан список типов ТЕ1$+. На этапе компиляции 
нужно получить константу, равную его длине. Эта константа должна быть статической, 
поскольку список типов является статической конструкцией, и естественно ожидать, что 
все вычисления, относящиеся к нему, выполняются именно на этапе компиляции. 

Идея, лежащая в основе большинства операций над списками типов, заключается 
в применении рекурсивных шаблонов, использующих для своего определения собст- 
венные конкретизации. При этом такие шаблоны передают разные списки шаблон- 
ных аргументов. Рекурсия, полученная таким способом, заканчивается явной специа- 
лизацией предельного варианта (Фог4ег саѕе). 

Код, вычисляющий длину списка типов, довольно лаконичен. 


хетрТасе <с1аѕ5 Ті151> 5їгисі і епдїһ; 
тетр1ате <> Ѕ1гист і епдёһ<ми11туре> 


епит { ма1ие = 0 У; 


; 
хетріасе <с1аѕ5 Т, с1аѕѕ Ц» 
Ѕ1гисСІ еподїћ< Туре11іѕ<т, у» > 
І 


епит { ма1ие = 1 +тепдтИ<у>: :маТие ); 
ЕД 

В переводе на человеческий язык, это означает: “Длина нулевого списка типов равна 
0. Длина любого другого списка типов равна 1 плюс длина его оставшейся части”. 

Реализация структуры іепдій использует частичную шаблонную специализацию 
(глава 2), позволяющую различать нулевой тип и список типов. Первая специализация 
структуры гепдтН является полной и соответствует только типу ми11туре. Вторая, частич- 
ная, специализация соответствует любому классу Туре11$1<т, Ч», включая составные 
списки, в которых класс О, в свою очередь, является классом Туреїі5їх«У, М». 


Глава 3. Списки типов 75 


Во второй специализации вычисления проводятся рекурсивно. Величина уа1ие в 
ней определяется как 1 (с учетом головы списка Т) плюс длина хвоста списка. Когда в 
хвосте списка остается единственный класс №и11туре, обнаруживается совпадение с 
первым определением, и рекурсия останавливается. В результате вычисляется величи- 
на, равная длине списка. Допустим, например, что нам нужно определить массив в 
стиле языка С, в котором содержатся указатели на объекты класса $14: : туре_1пФо 
для всех целочисленных типов со знаком. Используя структуру ГепдтИ, можно напи- 
сать следующий код. 


54: :туре_1пРо* іпїѕАТТі [1 епдсї«51ідпедіптедгаї 8»: :маТие); 


Во время вычислений на этапе компиляции в памяти будут размешены четыре 
элемента массива іпїѕ8111!. 


3.5. Интермеццо 


Впервые проблема шаблонных метапрограмм обсуждалась в книге Меійһиіғеп 
(1995). Затем эта тема глубоко изучалась в работе СтагпесКкі апа ЕізепесКег (2000), ко- 
торая содержала полную коллекцию имитаций выполнения операторов языка С++ на 
этапе компиляции программы. 

Идея и реализация структуры гепдеН напоминают классический пример рекурсии: 
алгоритм, вычисляющий длину односвязного списка структур. (Однако есть два суще- 
ственных отличия: алгоритм для структуры іепдїһћ выполняется на этапе компиляции 
и применяется к типам, а не к значениям.) 

Возникает вопрос: можно ли разработать итеративный, а не рекурсивный вариант 
структуры гепатһ? Помимо всего прочего, итерация более естественна для языка 
С++, чем рекурсия. Ответ на этот вопрос приведет нас к реализации других функ- 
циональных возможностей класса Туре1151. 

Ответ оказался отрицательным по весьма интересной причине. 

Средства языка С++, предназначенные для программирования на этапе компиля- 
ции, состоят из шаблонов, целочисленных вычислений и определений типов 
(операторы туреде{). Посмотрим, как работает каждый из этих инструментов. 

Шаблоны — точнее, специализации шаблонов — представляют собой эквивалент опе- 
раторов 1+ на этапе компиляции. Как мы уже видели на примере реализации структуры 
епосі, специализация шаблона позволяет отличать списки типов от других типов. 

Целочисленные вычисления — это настоящие вычисления, которые осуществля- 
ются путем перехода от типов к значениям. Однако здесь есть одна особенность: все 
значения на этапе компиляции являются неизменяемыми (пипииаЫе). Определив цело- 
численную константу, скажем, перечислимое значение, программист не может его в 
дальнейшем изменять (например, присваивать одно значение другому). 

Определения типов (операторы їурейе#) могут рассматриваться как введение кон- 
стант, задающих имя типа. И вновь после определения все эти имена оказываются 
зафиксированными — в дальнейшем переопределить символ, введенный оператором 
хуредеї, невозможно. 

Эти две особенности вычислений на этапе компиляции делают их принципиально 
несовместимыми с итерациями. Во время итераций вычисляется значение итератора, 


1 Этот массив можно инициализировать, не прибегая к повторению кода. Предлагаем чита- 
телю решить эту задачу самостоятельно. 
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причем оно может изменяться при выполнении некоторых условий. Поскольку на 
этапе компиляции переменных сущностей нет, выполнять итерации совершенно не- 
возможно. Следовательно, хотя язык С++ в основном является императивным, любые 
вычисления на этапе компиляции должны опираться на методы, характерные для 
чисто функциональных языков, которые отличаются тем, что не могут изменять зна- 
чения. Итак, без рекурсии не обойтись. 


3.6. Индексированный доступ 


К элементам списка типов желательно иметь индексированный доступ. Это позво- 
лит организовать линейный доступ к элементам, упрошая манипуляции со списками. 
Разумеется, как и все остальные сущности, с которыми мы работаем, индекс должен 
быть статической величиной. 

Объявление щаблона для индексированной операции может выглядеть следующим 
образом. 

тетр1ате «сТа55 т.151, ипѕідпеа їпс іпдех» $зхгист Туредт; 


Перейдем к определению алгоритма. Следует иметь в виду, что использовать изме- 
няемые значения нельзя. 

туредт 

Входные данные: список типов Т115ї, индекс 1 

Результат: внутренний тип Кеѕи1є 


Если список ті1іѕ1 не пуст и индекс 1 равен нулю, 
то класс Кеѕи1є — это голова списка ті 151. 
Иначе, 
если список ті 151 не пуст и индекс і не равен нулю, 
то класс Вези1{ получается путем применения алгоритма Туредт 
к хвосту списка ТЕТ5 и индексу 1-1. 
Иначе происходит выход за пределы допустимого диапазона изменения индекса, 
который Порождает сообщение об ошибке на этапе компиляции. 


Ниже приведено воплощение алгоритма Туредт на языке С++. 


тетр1ате «сТа55 Неа, с1аѕѕ Таї1»- 
$тгисЕ Туредє<Туре1151<Неаа, Та11>, 0» 
{ 


туредеҒ Неа везу]1т; 


хетрТаге <с1аѕѕ Неаа, с1аѕѕ Таї1, ипѕідпеа іпї і» 
ЅТгисТ Туредт<туре11$+<НеаЧ, таї1>, 1» 


туредеї турепате туредт<таї1, 1-1>::Веѕи1т Кеѕи1ї; 
; 

Если вы попробуете выйти за пределы допустимого диапазона изменения индекса, 
компилятор сообщит, что специализации Туредт<ми11туре, х> не сушествует. Здесь 
символ х означает величину, на которую вы превысили размер списка. Это сообшение 
могло бы быть более информативным, но сойдет и так. 

В библиотеке 10 (файл туре1151.һ) определен вариант структуры ТУредт под 
названием Туредтмопѕтгісті. Эта структура реализует некоторые функциональные 
возможности структуры Туредт с той лищь разницей, что выход за пределы допусти- 
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мого диапазона изменения индексов в ней запрещен менее строго и приводит не к 
порождению сообщения об ошибке на этапе компиляции, а к выдаче в качестве ре- 
зультата типа, заданного пользователем по умолчанию. Структура Туредтемопѕт гіст 
используется в обобщенной реализации обратного вызова, описанной в главе 5. 

Время индексированного доступа к элементам списка типов прямо пропорцио- 
нально размеру списка. Для списка значений этот метод неэффективен (по этой при- 
чине в классе 514::1157 не определена функция орегатог[1). Однако для списков 
типов время тратится на этапе компиляции и его объем не имеет большого значения.? 


3.7. Поиск элемента 


Как найти нужный тип в списке типов? Попробуем реализовать алгоритм Тпаехот, 
вычисляющий индекс типа в списке. Если тип не найден, результатом будет некото- 
рое фиксированное число, например —1. Этот алгоритм представляет собой классиче- 
скую рекурсивную реализацию линейного поиска. 

тпаехоғ 

Входные данные: список типов ТЕЛЕ, тип Т 

Результат: внутренняя статическая константа уа1ие 


Если список Ті 151 состоит из единственного типа Ми11Туре, 
то значение уаЛие равно —1. 
Иначе, если в голове списка ТЕ1$1 находится тип Т, 
то значение маПие равно 0. 
Иначе 
вычислить результат алгоритма тпдехо+, применяя его к хвосту списка 
т115є и типу Т, и присвоить его переменной тепр. 
Если значение тетр равно -1, то значение ма1ие равно -1. 
Иначе значение уа1ие равно 1 плюс тетр. 


Алгоритм тп4аехо+ относительно прост. Особое внимание уделяется передаче зна- 
чение уа1ие ("тип не найден”) в качестве результата. Последняя ветвь алгоритма 
(вычисление значения маїие в зависимости от значения Еетр) представляет собой 
операцию над числами и выполняется с помощью условного оператора ?:. Ниже при- 
водится реализация алгоритма. 


тетр1ате <с1аѕ55 Т\15е, с1аѕ5 Т> ѕтгисї Іпаехо#; 


тетр1ате <с1аѕ5 т> 
5єгисс Іпаехоғ<ми11Туре, Т> 


епит { ма1ие = -1 ); 


}; 


Ттетр1ате <с1аѕ5 Т, с1аѕѕ Таї1» 
5тгиСЕ ІпдӢехоҒ<Туре1151<Тт, Таї1>, т> 


2 На самом деле при разработке больших проектов это не совсем так. Возможна ситуация, 
по крайней мере теоретически, когда сложные манипуляции со списками типов смогут сущест- 
венно замедлить компиляцию программы. В любом случае программа, содержащая очень длин- 
ный список типов, либо очень долго выполняется (и тогда лучше смириться с долгой компиля- 
цией), либо является слишком сложной (и тогда ее следует разработать заново). 
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{ 


епит{ уаЛие = 0 У; 


Тетр1аїе <с1аѕѕ неаа, с1аѕѕ Таї1, с1аѕѕ т> 
5сгисс ІпаехоЁ<туре1їѕт<неаа, Таї1», т> 


ргімате: 

епит { тетр = ІпдехоҒ<таі1, Т»::маТиєе ); 
рибТтіс: 

епит { уа1ие = Тепр == -1 7 -1 : 1 + сетр ); 
}; 


3.8. Добавление элемента 


Нам нужно иметь возможность добавлять в список типов новый тип или список 
типов. Поскольку модификация списка типов невозможна, будем выполнять “возврат 
по значению”, создавая новый список типов, содержащий результат. 

Аррепа 

Входные данные: список типов Ті1$1, тип или список типов т 

Результат: определение внутреннего типа Везиї 


Если список ті 157 состоит из единственного типа Ми11туре 
и параметр Т является типом Ми11туре, 
то класс Вези]1+ является типом Ми11Туре. 
Иначе, если список Ті. $1 состоит из единственного типа Ми1]Туре 
и параметр Т является отдельным типом (а не списком типов), 
то класс вези1т является списком, состоящим из единственного элемента Т. 
Иначе, если список Ті 1515 состоит из единственного типа Ми11Туре 

и параметр Т является списком типов, | 
то класс Вези1т является типом т. 

Иначе, если список Ті 15ї не состоит из единственного типа миї1Туре, 
то класс Вези1т является списком типов, головой которого является 
тип т1.1517::неай, а хвостом — результат добавления списка т к элементу 

ТЕ151;:Та11 в качестве хвоста. 


Этот алгоритм естественно выражается следующим кодом. 
сетр1ате «сТа55 ТЬ1$т, с1аѕѕ т> $хгисе Аррепа; 


сетр1ате <> ѕїгисї Аррепа<ми11туре, №и11туре> 


Хуредеї ми11туре вези]т; 


сетр1ате «сТа55 т> з%гис® Аррепй<ми11туре, т> 


Туредеї ТҮРЕСІЅТ_1(Т) вези]т; 


тетрТаге «сТа55 Неа, с1аѕѕ Таї1» 
$Егисе Аррепд<Ми]]Туре, Туре1151<Неаа, таї?)» > 


хуредеї тТуре]151<неад, Та1]> Вези1с; 
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$}; 


тетрТате <с1аѕѕ Неаа, с1аѕѕ Таї1, с1аѕѕ т> 
5ггист Аррепа<Туре1151<Неаа, таїі>, т> 


туредеї туре|15т<неа4, 
турепате Аррепӣ<Таї1, Т»::Везиїт» 
везиї і; 

$; 

Обратите внимание на то, как последняя частично специализированная версия 
структуры Аррепа рекурсивно конкретизирует шаблон Аррепа, передавая ему хвост 
списка и добавляемый тип. 

Теперь для типов и списков типов определена унифицированная операция Аррепа. 
Например, приведенный ниже оператор определяет список, состоящий из всех число- 
вых типов со знаком, прелусмотренных в языке С++. 

гуредеї Аррепа<51дпейІптедга15, 

ТҮРЕГїЅТ 3 СҒ1оат, дфоцбТе, Топд доџб1е)»>: : Вези]т 
519педТурез; 


3.9. Удаление элемента 


Рассмотрим теперь обратную операцию — удаление элемента из списка типов. У 
нас есть две возможности: удалить только первое вхождение или удалять все вхожде- 
ния данного типа в списке. 

Изучим только первый вариант 


ЕГазе 
Входные данные: список типов Тії51, типт 
Результат: определение внутреннего типа Вези1 


Если список Ті 157 состоит из единственного типа Ми] Туре, 
то класс веѕи1т является типом Ми туре. 
Иначе, если тип Т совпадает с типом ТЕ1 $1: :Неаа, 
то класс Веѕи1т является типом ТЕТ$Т: : Тат 1. 
Иначе 
класс кеѕи1т является списком типов, голова которого является 
типом Ті151: :Неай, а хвостом — результат применения алгоритма Егаѕе 
к хвосту Ті151:Таї] с параметром т. 


Вот как выглядит этот алгоритм на языке С++. 


тетрТате <с1аѕѕ ТЁ1$%, с1аѕѕ Т> ѕїгист Егазе; 
тетр1ате <с1аѕ5 Т» // Специализация 1 
5тгист Егаѕе<ми11Ттуре, Т» 


туредеї миїїтуре веѕи1т; 


, 


тепрТаге <с1аѕ5 Т, с1аѕ55 Таї 1» // Специализация 2 
$тГиСТ ЕГазе<туре11$т<т, Таі1>, т> 


Туредеї таї! вези1т; 


тетрТате <с1аѕѕ неа, с1аѕ5 Тат], с1аѕѕ т > // Специализация 3 
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$тгисЕ Егазе<туре11$т<НеаЧ, Таї1>, т> 


туредеї туре11$т<неаа, 
Турепате Егаѕе<Таі1, Т>: : Кези1 {> 
Кеѕи1+; 


}; 

Как и для класса Туредт, для этого шаблонного класса не предусмотрен вариант 
по умолчанию. Это означает, что класс Егазе можно конкретизировать только опре- 
деленными типами. Например, выражение Егазе<доц6]е, іпї> вызовет ошибку 
компиляции, поскольку для него не существует ни одного соответствия. Кроме того, 
необходимо, чтобы первый параметр шаблонного класса Егаѕе был списком типов. 

Используя определение класса ѕіпдейтуреѕ, можно записать следующее. 

// Класс ѕомеѕідпейтуреѕ содержит эквивалент класса 

// ТУРЕЕТЗТ_6(э1дпе4 сНаг, 5Погі їпі, 1пе, Топд іп, 

// доче, Топд доцьїе) 

ТурейеҒ Егаѕе<5ідпейтуреѕ, ЕТоаф>::кези]е 5опте5ідпейтТурез; 

Рассмотрим рекурсивный алгоритм удаления элементов. Шаблон ЕгаѕеА11 удаляет 
все вхождения типа в список типов. Его реализация аналогична классу Егазе, за од- 
ним исключением. При обнаружении типа, подлежашего удалению, алгоритм не ос- 
танавливается, а продолжает искать и удалять соответствующие элементы из хвоста 
списка, рекурсивно применяя самого себя. 


тетр1ате <с1аѕ5 тіїѕї, с1а$$ Т> ѕ1гисї Егаз5едії; 


тетр1ате <с1аѕ55 Т> 
ѕ1ігисї ЕгаѕеА11<№и11туре, Т> 


хуредеї ми11туре Кеѕи1+; 
тетр1ате <с1аѕ5 Т, с1аѕ Таї1» 
ѕ1ігисї ЕгаѕеА11<Туре1151<т, Таі1>, т> 


// проходит вниз по списку, удаляя заданный тип 
хуредеї турепате ЕғаѕеА11-<Ттаї1, т>: :Веѕи1є Веѕи1+; 


тетр1ате <с1аѕѕ неаа, с1аѕѕ Таї1, с1аѕѕ т> 
$тгиСЕ ЕгаѕеА11<Туре1156<Неаа, Таі1>, т> 


// проходит по списку, удаляя заданный тип 
хуредеї Туре115ї<Ннеаа 
Турепате ЕгаѕеА11<Ттаі1, т>: : Кеѕи1 т> 
Кези] т; 
$}; 


3.10. Удаление дубликатов 


Важной операцией над списками типов является удаление дубликатов. Ее цель — 
трансформировать список типов так, чтобы каждый тип в списке встречался лишь 
один раз. Например, из списка 


ТУРЕЕТЗТ_6(\1Адет, Виссоп, мТадет, Техтғіе1а, 5сгоїїваг, Виссоп) 


нужно получить список 
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ТҮРЕС15Т__6 (мі ідеї, Виссоп, ТехтЕїе1а, ѕсго11ваг) 


Эта процедура немного сложнее, однако, как легко догадаться, нам поможет класс Егаѕе. 
Морир1їсатеѕ 
Входные данные: список типов ТЕЛ $ 
Результат: определение внутреннего типа Вези1* 


Если список Т1 15 состоит из единственного типа ми11туре, 
то класс Кеѕи1+ является типом Ми11тТуре. 
Иначе 
применить алгоритм Морир1ісатеѕ к списку ТЕЛ 5%: : Та1 1, 
получив временный список 11; 
применить алгоритм Егазе к списку Ті151: :Неаа, 
получив в результате список 12. 
Класс Веѕџ1т — это список типов, голова которого является 
списком ТЕТ$т: : Неа4, а хвост — списком 12. 


Вот как этот алгоритм переводится на язык С++. 
тетр1асе «сТа55 ТЕТ$%> 5 сгисі Мобир11сате$; 


тетрТате <> 5сгисс морир1ісатеѕ<ми11туре> 


хуредеї ми11Туре Кеѕи1т; 
тетр1ате «сТа55 неа, с1аѕѕ Таї1» 
ѕТгисе МобирТісате5« Туре11ї51<Неаа, таї1» > 


ргімате: 

Хтуредеї турепате Мобир]1сате$<Та11>: : Вези]т 11; 

хтуредеї турепате Егазе<11, Неа4>: : вези]1т 12; 
риБ1їс: 

туреде#Ғ Туре1151<Неаа, 12> веѕи1+; 

Почему мы воспользовались алгоритмом Егаѕе, имея в своем распоряжении алго- 
ритм Егазед11? Ведь мы хотим удалить все дубликаты данного типа, не правда ли? 
Ответ заключается в том, что алгоритм Егаѕе применяется после рекурсивного вызова 
алгоритма Мобир11сате$. Это означает, что мы удаляем из списка тип, у которого уже 
нет дубликата, поэтому в списке останется по крайней мере один экземпляр данного 
типа. Это довольно интересный пример рекурсивного программирования. 


3.11. Замена элемента 


Иногда вместо удаления нужно заменить какой-то элемент в списке типов. Как 
мы увидим в разлеле 3.12, замена одного типа другим представляет собой важную 
строительную конструкцию для многих сложных идиом. 

Допустим, что нам нужно заменить тип т типом у в списке типов ТІ157. 

ВерТасе 

Входные данные: список типов ті1ѕ+, тип Т (подлежащий замене) и тип Ч 

(замена) 
Результат: определение внутреннего типа Вез5и1 є 
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Если список Ті 157 состоит из единственного типа Ми11туре, 
то класс Кеѕи\іт является типом Ми11туре. 
Иначе, если голова списка Ті 155 является типом т, 
то класс Кеѕи1т представляет собой список типов, 
у которого голова является типом О, а хвостом служит список 
ТЕ1 51; : Та]. 
Иначе класс вези1* представляет собой список типов, 
у которого голова является списком ТЕ1 51: :Неай, 
а хвостом служит результат применения алгоритма Веріасе 
к списку Т115т и параметрам и у. 


Вот как выглядит код этого рекурсивного алгоритма. 
тетр1ате <с1аѕ5 т.151, с1аѕѕ т, сТаз55 Ц» з+гисе вер1асе; 


Тетр1ате <с1аѕ5 Т, С1аѕ5 Ц» 
ѕтгист кер1асе<ми11туре, т, Ц» 


хуредеї №и11туре вези1т; 


тетр1ате <с1а5$ Тт, с1аѕѕ Таі1, с1аѕѕ Ц» 
5т7гисі ЋКер\асе<туре1151<Тт, Таїї», Т, у» 


туреде{ Туреїі5с«ю, Таї1» везут; 
р 
тетр1ате «с1а55 неай, с1аѕѕ Таї1, с1аѕѕ т, сТа55 0» 
5сгисс ВерТасехТуреїі5єс«неад, Таї1>, т, и> 


хуредеї Туреїі5є«Неад, 
турепате Кер1асе<Таі1, т, 1: : Веѕи1т 
Кеѕи1т; 
}; 
Алгоритм верТаседії легко получить, изменив вторую специализацию так, чтобы 
в ней алгоритм рекурсивно применялся к списку Та11. 


3.12. Частично упорядоченные списки типов 


Допустим, нам нужно упорядочить список типов По отношению наследования. 
Например, мы бы хотели, чтобы производные типы предшествовали базовым. Пусть 
мы имеем иерархию классов, изображенную на рис. 3.1. 

Предположим, что у нас есть список типов 

ТУРЕЕТЗТ_4(\19дет, 5сгоїїваг, Виссоп, сгарпісвистоп) 

Наша задача -- преобразовать его следуюшим образом: 

ТУРЕГІ5Т, 4(5сгоїТВаг, сгарһћісвиссоп, Виссоп, міадеї) 


Следовательно, нам нужно переставить производные классы вперед, оставив порядок 
следования классов одинакового уровня ($1118) прежним. 

На первый взгляд эта задача кажется надуманной, однако она имеет большое 
практическое значение. Просмотр упорядоченного списка типов, в котором произ- 
водные типы стоят впереди, соответствует обходу иерархии классов снизу вверх. Ме- 
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ханизм двойной диспетчеризации, описанный в главе 11, применяет это важное свой- 
ство для распознавания информации о типах. 


ЅсгоіВаг 


ОгарһісВийоп 


Рис. 3.1. Простая исрархия классов 


Для упорядочения набора необходима соответствуюшая функция. У нас уже есть стати- 
ческий механизм распознавания наследования, детально описанный в главе 2 Напомним, 
что в нашем распоряжении есть удобный макрос $ИРЕВЗУВСЬА$$(Т, Ц), возвращающий 
значение тгие, если класс Ц является производным от класса т. Мы просто объединим ме- 
ханизм распознавания наследования со списками типов. 

Применение к спискам типов полноценного алгоритма сортировки невозможно, 
поскольку у нас нет отношения полной упорядоченности между типами. По этой 
причине для классов невозможно создать эквивалент оператора сравнения орегатог<. 
Следовательно, нам придется использовать особенный алгоритм, переставляющий 
производные классы вперед и не изменяющий отношения между другими классами. 

брегімедтовгопі 

Входные данные: список типов Тії51 


Результат: определение внутреннего типа Вези1 г 


Если список ТЕЛ 5т состоит из единственного типа ми11туре 
то класс Кеѕи1т является типом Ми11туре. 
Иначе 
найти в списке Ті1ї51::Таї1 класс самого нижнего уровня, 
производный от класса ТЕТ 5т: : Неа. Сохранить его во 
временной переменной тһемоѕ трегімеа. 
Заменить класс тћемоѕтреѓімеа в списке ті151: :Та11 
списком Тії51: : Неа, получив в результате список і. 
Сконструировать результат в виде списка типов, головой которого является 
класс тћемоѕтрегімеа, а хвостом — список і. 


Во время применения этого алгоритма к списку типов производные типы переме- 
щаются на вершину, а базовые типы заталкиваются на дно. 


В этом описании нет одной детали — алгоритма обнаружения производного класса 
самого нижнего уровня в заданном списке типов. Поскольку макрос 50РЕКЅ0ВСІА55 
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во время компиляции порождает булевское значение, для решения этой задачи оказы- 
вается полезным небольшой шаблонный класс 5еТесі (также описанный в главе 2). 
Напомним, что этот шаблонный класс выбирает один из двух типов в зависимости от 
значения булевской константы. 

Алгоритм тһемоѕтрегімеа получает на вход список типов и тип Ваѕе, а возвраша- 
ет — наиболее глубоко вложенный класс, производный от типа Ва5е, находяшийся в 
списке (или, возможно, сам класс Ваѕе, если производных типов в списке нет). 


Мо5 Сбег'імед 
Входные данные: список типов ТЕЛ, тип Т 
Результат: определение внутреннего типа Веѕи1т 


Если список ТІ. 151 состоит из единственного типа Ми1 1Ттуре 
то класс Веѕи1 является типом т. 
Иначе 
применить алгоритм мо5 бегімеа к списку т.151: :Таі1 и типу Вазе. 
Получить тип Сапаї дате. 
Если тип т.156: :Неа4 является производным от типа Сап@1дате, 
то результатом является тип т.151: :Неа4. 
Иначе результатом является тип Ссап@1 дате. 


Реализация алгоритма Моѕтрегіхмеа выглядит следующим образом. 
тетр1ате <с1аѕѕ тііѕт, сТіа55 т> ѕїгист Моѕтрегімеа; 


хетрТате «сТа55 т> 
5сгисі Моѕсрегімей<№и11туре, т> 


б 
суреде? т вези]1хт; ' 
; 
тетр1ате «сТа55 Неа, с1аѕѕ Таї?, с1аѕѕ т> 
5сгисі МоѕТтрегіуей<туре1іѕт<неайӣ, Та11>, т> 


ргімате: ; 

туредеї турепате Моѕтрегімей<таі1, т>: :Кеѕи\т Сапаїдате; 
роиб11с: 

ТуредеҒ турепаме ЅеЛест< 

ЅЦРЕКЅОВСІА55 (Сапаі дате, неаа), 
Неаа, Сапа1дате>: : кеѕи1т Ккеѕи1т; 
$}; 
Алгоритм регіуеатоЕгопї использует алгоритм Моѕїрегімеа в качестве элемен- 
тарного алгоритма. Вот его реализация. 


тетр1ате «сТа55 т> зтгист Оегімедторргопі; 


тетр\ате<> 
ѕтгист регтіуеатоЕгопї <ми1 1туре> 


туреде{ ми11туре кеѕи1+; 


тетр1ате «сТа55 Неаа, с1аѕѕ Таї1» 
ѕїігист регіуеатоғгопс< туре1іѕт<неаа, таї1> > 
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ргіхате: 
суреде сурепате Моѕ®регімей<Таї1, неа4>:; : Кеѕи1т 
тһемоѕтрегімеа; 
туреде{ сурепате Кер1асе<таї1, 
тһемоѕ Трегімей, 'Неад>: : Вези]1 т |; 
рчЬ1їс: 
сурейеҒ туре11ѕс<тһемоѕрегімей, > Веѕи1т; 
}; 


Эта сложная манипуляция со списком типов обладает замечательной силой. Пре- 
образование регіхуеатоғгопї эффективно автоматизирует обработку типов, которую 
иначе пришлось бы долго и тщательно реализовывать вручную. Это напоминает авто- 
матическую поддержку параллельных иерархий классов, не так ли? 


3.13. Генерация класса на основе списка типов 


Если до сих пор списки классов казались интересными, интригующими или даже 
ужасными, то это только цветочки. В этом разделе дается определение основных конст- 
рукций для генерации кода с помощью списков типов. Это означает, что мы вообще 
болыше не будем писать программы, а заставим компилятор делать это за нас. Такие кон- 
струкции основаны на одной из самых мощных особенностей языка С++, которой нет ни 
в одном другом языке, — шаблонных шаблонных параметрах (гетріаге 1етр/ае рагатеег). 

До сих пор манипуляции со списками типов не порождали никакого кода. В ре- 
зультате обработки возникал новый список типов, типы или числовые статические 
константы (как в классе (еп). Перейдем к изучению процесса генерации реального 
кода, Т.е. к тем сушностям, которые оставляют свой след в скомпилированном коде. 

Объекты списков типов и здесь не нужны. Они не имеют никакого значения во 
время выполнения программы и никаких функциональных возможностей. При работе 
со списками типов особо важна возможность генерировать код на основе списка ти- 
пов. Прикладные программисты иногда должны наполнять класс каким-то кодом — 
сигнатурами виртуальных функций, объявлениями переменных или реализациями 
функций. Способ этого заполнения определяется списком типов. Попытаемся автома- 
тизировать этот процесс. 

Поскольку в языке С++ нет статических итераций или рекурсивных макросов, за- 
дача добавления кода для каждого типа, содержашегося в списке, довольно сложна. 
Можно применить частичную шаблонную специализацию в сочетании с описанными 
выше алгоритмами, но реализация этого решения будет слишком запутанной и слож- 
ной. Решить эту задачу нам поможет библиотека [окі. 


3.13.1. Генерация распределенных иерархий 


Мошные шаблоны библиотеки [.окі облегчают задачу построения классов путем 
применения каждого типа, содержашегося в списке типов, к основному шаблону, 
предоставленному пользователем. Таким образом, запутанный процесс распределения 
типов, указанных в списке, по программе пользователя инкапсулирован в библиотеке. 
Пользователь должен лишь определить простой шаблон с одним параметром. 

Этот шаблонный библиотечный класс называется Сеїѕсассегніегагсћу. Несмотря 
на то что его определение достаточно просто, этот класс невероятно эффективен. Вот 
его определение.?3 


3 Это одна из ситуаций, когда предпочтительнее сначала описать идею и лишь затем — ее 
потенциальные приложения (в отличие от обычного порядка решения задач). 
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хетрТасе «сТа55 ТЬ15%, СетрТаге «сТа55» с1аѕѕ цп11> 
с1аѕ5 бепбсаттегн1егагсНу; 
// Специализация класса беп5сассегніегагсНу: 
// преобразование класа туре115ѕї в класс упії 
хетрТасе <с1аѕ5 Т1, сТа55 Т2, тетрТате <с1аѕѕ> с1аз5 Цпії» 
сТа55 сепбсаттегнТегагсНу<Туре!.15*<Т1, Т2», Цпіс» 
рибТбіс сепѕсаттегніегагсћу<т1, піс», 
руБ11с сепбсассегніегагспує ті, упіт> 


1 

рибТіс: 

туредеї Туре1151<т1, Т2» 115%; 

туредеї бепѕсаттегніегагсһу<т1, піс» цеїтВазе; 
ТтурейеҒ Сепѕсатсегніегагсһу<т2, Цпіс» кідһЕВаѕе; 


; 
// передача атомарного типа (не списка типов) классу йпії 


тетр1ате <с1аѕ5 АсотісТуре, тетр1ате «сТа55» сТа55 пір» 
с1аѕ5 сепѕсаттегніегагсһу : рибТіс опіт<АТортістуре> 


Турейе? Чпі ї<Атотістуре> ге{\Вазе; 


// С классом №и11туре не делаем ничего 

тетр1ате <тетр1ате <с1аѕѕ> с1аѕѕ піт» 

сТа55 Сепѕсатсегніегагсһу<ми11Ттуре, піс» 

{ 

У; 

Шаблонный шаблонный параметр работает так, как и ожидалось (глава 1). Шаб- 
лонный класс Упіє передается классу СепѕсатсегНіегагсћһу в качестве второго аргу- 
мента. Класс сеп5сассегніегагспу использует свой шаблонный шаблонный пара- 
метр уп1т как обычный шаблонный класс с одним шаблонным параметром. Новые 
возможности появляются благодаря тому, что пользователь класса беп$саттегн1егаг- 
сну может передавать єму свой собственный шаблон. 

Что делает класс Сбепѕсатїегніегагсһу? Если его первый аргумент является ато- 
марным типом (в противоположность списку типов), класс сеп5састегніегагспу пе- 
редает его классу Уп1* и, наследует свойства результирующего класса упіт<т>. Если 
первый аргумент является списком типов Т1151, класс Ссепѕсаттегніегагсһу сводит- 
ся (гесигѕеѕ) к классам бепѕЅсаттегНіегагсһу<ті151: :Неаа, упіт> и беп5саїтегні- 
егагсһу<ті151::Таї1, упії> и наследует их свойства. Класс Сепѕсаїттегніегаг- 
сһу<ми11туре, ипіт> является пустым. 

В итоге процесс конкретизации класса сепѕсаїтегніегаѓсһу заверщается насле- 
дованием класса упіт, конкретизированного каждым типом из списка типов. В каче- 
стве примера рассмотрим следующий код. 


тетр1ате <с1аѕ5 т> 
зсгист но1аег 


т уа1ие_; 


У 


Ттурейе? сес5састегніегагспух 
ТУРЕЦІ5Т. 3(їпс, 5сгіпд, и1адет), 
но1аег> 

мі адетІп?о; 
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СепбсайегНіегагспу СепбсайегНіегагсһу 
<МЛадеї,НоІдег> <МиПуре,Но!ег> 


СепЅсайегНіегагсһу СепЅсайегНіегагсһу 
<вїгіпо,Ноідег> СТУРЕЦІЯТ 1 (Младе?) Ноідег» 


СепЅсайегНіегагсһу СепЅсайегНіегагсһу 
«іпі Нокіег» <ТҮРЕЦЅТ 2 (ѕїгіпо, \УЛаде*),НоЧег> 


Уладентю 


Рис. 3.2. Структура наследования класса И/а0с11пјо 


Иерархия наследования, порожленная классом \1Чдеттифо, показана на рис. 3.2. 
Мы булем называть такие иерархии классов распределенными (зсаЦегеа), поскольку ти- 
пы в списке типов распределены по разным корневым классам. В этом заключается 
сущность класса бепзсастегнТегагсну — он генерирует иерархию классов для поль- 
зователя, многократно конкретизируя щаблонный класс, предоставленный ему в каче- 
стве модели. Затем он собирает все сгенерированные классы в один, в данном слу- 
чае — класс міддеєіпбо. 

В результате наследования классы но1аег<іпт>, но] 4ег<5%г1ид>, но14ег<и1адет> и 
мтадестиРо имеют одну переменную-член уа1ие_туре для каждого типа, указанного в 
списке типов. На рис. 3.3 показана бинарная схема объекта класса мі дфдестпбо. Предпо- 
лагаєтся, что такие пустые классы, как СепѕсаттегнНіегағсһу<ми11туре, Но14ег>, иг- 
норируются и не занимают места в составном объекте. 
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Объекты класса мі ддеттпТо позволяют делать интересные вещи. Например, можно 
обратиться к объекту класса 58 гіпд, хранящемуся в объекте класса міадеІпҒо, напи- 
сав следующий код. 


м1 адетіпЁо обі; 
5сгіпд паме = (5сасіс саз5'«НОТдег«5 є гіпа»в» СоБј) ) .уа1ие_; 


Явное приведение типов позволяет избежать неоднозначности имени уаЛћие_. В против- 
ном случае компилятор не сможет определить, на какой член уа1ие_ вы ссылаетесь. 


Младейпіо 


ИСИ, 
И, 
умадеї маше ; й 


Рис. 3.3. Схема распределения памяти для объекта класса Илаве тю 


Ноідвгаїпі» 


СепбсайегНівгагспу 


Ноїіегсвігіпд» З і 
<ТҮРЕЦ5Т _2(5 пд, Мет), Ноег> 


Нодег<ММаде> 


Это приведение типов выглядит ужасно, поэтому мы попытаемся облегчить работу 
с классом беп5састегніегагспу, снабдив его несколькими удобными функциями 
доступа. Например, было бы прекрасно иметь доступ к члену класса по его типу. Это 
довольно просто. 

// класс Ғіе1аӣтгаітѕ описан в файле ніегагсһусепегатогѕ.һ 

тетр1ате «сТа55 т, с1аѕѕ н> 


хурепате Ргіуате: : Ғіе1атгаітѕ<Н> : : кебіпа<т»> : : кеѕи1т& 
гле1а(н& обі) 
{ 


гетигп обі; 


Работа функции Ғіе1а основана на неявном преобразовании производного типа в 
базовый. При вызове РіеТа«міддет»(обі) (где обі должен иметь тип міадетіпҒо) 
компилятор распознает, что но дег«міддет» — это базовый класс по отношению к 
классу міадеїІп#о, и просто вернет ссылку на эту часть составного объекта. 

Почему функция Ғіе1а является частью пространства имен, а не функцией- 
членом? Потому что такой высокий уровень обобщенного программирования вынуж- 
дает очень осторожно обращаться с именами. Представьте, например, что в классе 
упі с определен символ с именем ЕЇїе14д. Если бы в классе сеп5саттегніегагсПпу была 
функция-член Е1е14, она бы была замаскирована функцией ғіе1а, являющейся чле- 
ном класса Џпітї. Это вызвало бы массу недоразумений. 

У функции Ғіе1а есть один недостаток: ее нельзя применять, если в списке типов 
есть дубликаты. Рассмотрим немного измененное определение класса мі адеїІпҒо. 

ТуредеҒ сепзсаттегнтегагсну< | 

ТУРЕЕТЗЬТ_4 (1пї, іп, 5%1г1иа, Міадеї), 
умаТив» 

м адесІпҒо; 

Теперь в классе міддеїІпҒо есть два члена уаїце , имеющих тип їпі. Если вы- 
звать функцию ғіе1а<іпт> из объекта класса міадестпіо, компилятор пожалуется на 
неоднозначность. Устранить эту неоднозначность нелегко, поскольку класс міддет- 
ТпРо дважды наследует свойства класса но] дег<тпт>, причем разными путями, как 
показано на рис. 3.4. 
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То же, что и на рис. 3.2 


СепЅсайегНіегагсћу СбепЅсайегНіегагсһу 
<іпі,Но!аег> <ТҮРЕЦТ 2(зігіпд, МЛаде!),НоЧег> 


Сеп$саќегНіегагсћу СепЅсайегНіегагсћу 
<тьНоег> <ТУРЕН$Т З(іпі, ѕїгіпо, Мадеї),НоІдег> 


Мліддекіпіо 


Рис. 3.4. Класс ИЛаве!и наследует свойства класса Ноіаег<іпі> дважды 


Нам необходимо средство, позволяющее выбирать поля в конкретизации класса 
сеп5сассегніегагспу на основе позиционного индекса (робійопа! іпаех). Если бы мы 
могли ссылаться на каждое из этих двух полей, имеющих тип іпт, в списке типов (Т.е. 
Еіе1а<0> (обі) и Еїе14<1>(оБј)), то неоднозначность была бы устранена. 

Попробуем реализовать функцию доступа к полю по его позиции в списке ти- 
пов. Нам нужно выполнить статическую диспетчеризацию для поля, имеющего ин- 
декс 0, что соответствует голове списка типов, и поля с ненулевым индексом, соответ- 
ствующего хвосту списка. Это довольно легко сделать с помошью небольшого шаб- 
лонного класса Іпі2Туре, определенного в главе 2. Напомним, что класс Іпї2Туре 
просто преобразовывает каждую отдельную целочисленную константу в отдельный 
тип. Кроме того, как показано ниже, для передачи полученного результата использу- 
ется класс Туре2Туре. 

тетрТафе <с1аѕ5 Н, турепате В» 


іп1іпе в& Еіе1ане1регсн& обі, туре2туре<А>, Іпї2Туре<0>) 


{ 
Турепате Н: :ЕеЁтваѕе& $6063 = обі; 
гетигп ѕибоБј; 


тетр1ате <с1аѕ5 н, турепате в, іп і» 
1111пе в& Ғіе1ане1рег(Сн& обі, ТуредТуре«к» ТЕ, тпЕ2туре<1>) 


хурепате н: :відһіваѕе& 5ибобі = обі; 
гетигп ЕТеТднеТрег(5цобі, ++, тпе2туре<1-1>()); 
} 
// Класс Еїебатгаїс5 описан в файле Ніегагсһубепегатогѕ.һ 
тетр1ате <іпї 1, сіа55 н> 
хепріаге Рсічате: : Е1е14тгаі5<Н> : : Ас<і>: :Кезиї би 
Е1е14(н& обі) 
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хтуредеї турепате Ргіуате: : Ғіе1атгаїтѕ<н> : :Ат<1> ; : Кеѕи1ї 
Кези] с; 
гетиги ЕТеТанеТрег(орі, туре2Туре<Кеѕи1 т> 0), Іпї2Туре<1>(0)); 


Остается понять, как написана такая реализация, но, к счастью, это достаточно 
легко объяснить. Всю работу выполняют две перегруженные функции Ғіе1ане1рег. 
Первая из них получает параметр, имеющий тип Іптї2Туре<0>, а вторая — параметр 
ІСП2Туре<любое целое число». Следовательно, первая перегруженная функция возвра- 
щает значение, соответствующее классу упітї<т1>&, а вторая — тип, имеющий ука- 
занный индекс в списке типов. Для того чтобы определить, какой тип следует вер- 
нуть, функция ЕїеТа использует вспомогательный шаблонный класс Ғіе1атгаії5ѕ. 
Функция Е1е14 возвращает этот тип функции Ғіе14не1рег через класс Туре2туре. 

Вторая перегруженная функция ғіе1ане1рег рекурсивно вызывает саму себя, пе- 
редавая правого предка класса СепЅсатїтегніегагсһу и тип Іпї2Туре<іпдӣех-1>, по- 
скольку поле М в списке типов является полем №1 в хвосте этого списка, если М не 
равно нулю. (Действительно, случай, когда М равно нулю, обрабатывается первой пе- 
регруженной функцией.) 

Чтобы упростить интерфейс, нам нужно предусмотреть в классе Ғіе1а две допол- 
нительные функции: константные версии двух определенных выше функций ЕЇе14. 
Эти функции очень похожи на свои неконстантные прототипы, но, в отличие от них, 
принимают и возвращают ссылки на константные типы. 

Функция Ғіе1а намного облегчает использование класса Сепѕсаїтегніегагсћу. 
Теперь можно написать следующий код. 


итадестптРо об); 


Чит х = ЕТеба«0» Сорі).маїие ; // первый целый тип 
іпо х = Ріе14<1> (057) .уа1ие_; // второй целый тип 


Шаблонньй класс бепѕсаттегніегагсһу очень удобен для генерации сложных 
классов на основе списков простых типов. Класс Сепѕсасёсегніегагсһу можно при- 
менять для генерации виртуальных функций для каждого типа в списке. В главе 9, 
посвященной абстрактным фабрикам, этот класс используется для генерации абст- 
рактных производящих функций, работающих со списками типов. В этой главе также 
показано, как реализуются иерархии, порожденные классом Сепѕсаїтегніегагсћһу. 


3.13.2. Генерация кортежей 


Иногда возникает необходимость создать небольшую структуру, состоящую из бе- 
зымянных полей, известную в некоторых языках (например, в языке МГ.) под назва- 
нием кортеж (кмріє). Создание кортежей на языке С++ впервые было описано в ра- 
боте Якко Ярви (1аККо Лагл, 1999а), а затем уточнено в работе (Јӣгуі апа Роже], 19996). 

Что такое кортеж? Рассмотрим следующий пример. 


тетр1ате <с]а5$$ т> 
Ѕігисї но1аег 


т уа1ие_; 


}; 


туредеї сепѕсаттегніегагсһу< 
ТУРЕЦІ5Т, З(їпс, іп, їпо), 


Глава 3. Списки типов 91 


но] 4ег> 
Ро1пт30; 


Работать с классом Ро1пт30 довольно трудно, поскольку после каждой функции 
доступа к полям необходимо указывать суффикс .маТие . Нам нужно создать струк- 
туру, похожую на класс СепЅсаттегніегагсћһу, в которой функции доступа Ғіе1а воз- 
вращают ссылки непосредственно на члены ма1ие_. Это значит, что функция 
Еіе1а<п> должна возврашать не но1аег<іпт>, а іпт&. 

В библиотеке ГоК определен класс Тир1е, реализованный аналогично классу беп- 
Ѕсаттегніегагсһу, но предоставляющий прямой доступ к полям. Этот класс работает 
следующим образом. 

туредеї тир1е<ТУРЕЕТЬТ_3(1пЕ, їпі, 1пт)> 


Роіпі30; 
Роіпї30 рт; 
Е1е14<0> (рї) = 0; 
Еіе1<1> (рт) = 100; 
Е1е14<2> (рт) = 300; 


Кортежи полезны для создания небольших безымянных структур, не имеющих 
функций-членов. Например, с их помощью можно возвращать из функции сразу не- 
сколько значений. 

тир1е<ТҮРЕШІЅТ_3 (їп, іп, іп)» 

сем паомР1асетепт (м1 п4ом&) ; 

Фиктивная функция Сеїмі паомР1асетепті позволяет пользователям узнавать коор- 
динаты окна и его положение в стеке окон, используя один вызов функции. При этом 
разработчик библиотеки не обязан предусматривать отдельную структуру для кортежа, 
состоящего из трех целых чисел. 

Другие функции, работающие с кортежами, можно найти в файле Тиріе.П биб- 
лиотеки ои. 


3.13.3. Генерация линейных иерархий 


Рассмотрим следующий простой шаблонный класс, определяющий интерфейс об- 
работчика события. В нем определяется только функция-член ОпЕмепт. 


тетр1ате <с1аѕѕ т> 
с1аѕѕ Емепїнапа1ег 


рчб1їс: 
мігсца?) моїд ОпЕмепс(соп5С Те, їпо еуептт4) = 0; 
мігтџа1 моїд -Емептнап Ч ]егО) 1) 
Р 
В классе Емептнапа1ег определен виртуальный деструктор, не представляющий 
для нас интереса, но тем не менее необходимый (причины будут указаны в главе 4). 
Шаблонный класс бепѕсаттегніеғгагсһу можно использовать для того, чтобы рас- 
пространить класс Емептнап Тег на каждый тип в списке. 


туре4еЁ Сепѕсаттеғніегагсһу 


< 
ТУРЕЕТЗТ_3 (мі падом, Виссоп, ѕсго11ваг), 
Еуептнапа1ег 

> 

мтіадетЕмептнапа1ег; 
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У класса бепѕсатсегніегагсһу есть недостаток — он использует множественное 
наследование. Если размер кода очень важен, этот класс может стать непригодным, 
поскольку класс \1ддетЕуептнап1Лег содержит три указателя на виртуальные табли- 
цы“, по одной для каждой конкретизации класса Еуепіснапаїег. Если величина 
ѕ51геоЁ(Еуепєнапад1ег) равна 4 байт, то величина $17ео#(\14дехЕуепНапаТег) бу- 
дет равна уже 12 байт, возрастая по мере добавления в список новых типов. Наиболее 
эффективно было бы объявлять все виртуальные функции внутри класса и14детЕуеп- 
хнапаТег, правда, это не позволило бы генерировать код. 

Линейная иерархия наследования позволяет разложить класс м19детЕуептнапт Тег 
на классы, по одному на каждую виртуальную функцию, как показано на рис. 3.5. 
При использовании простого наследования класс м1ддетЕуептнап9Лег может иметь 
только один указатель на виртуальную таблицу, что максимально повышает его эф- 
фективность с точки зрения размера. 


НапаіегЅсгоБаг 
ОпЕмепѕспі : ЅсгоіВаг&, ечепіа : іпі) 


А 


НапдегВиНоп 
ОпЕмепЫп : Вийопё&, емепіїа : п 


ми 
А 


НапаїегМіпаом 
ОпЕуеп мпа : Ипаом&, емепіа : іпі) 


Д 


УМіадеївменіНапаївт 


Рис. 3.5. Оптимальная по размеру 
структура класса ИлавеЕуетНанйег 


Как создать механизм, автоматически генерирующий такую структуру? Для этого 
предназначен рекурсивный механизм, аналогичный классу бепбсастегніегагсНу. 
Однако есть одно отличие. Шаблонный класс, определенный пользователем, теперь 
должен принимать два шаблонных параметра. Один из них является текущим типом в 
списке типов, как и у класса СсепѕсаїтћегнНіегагсћу, а второй — это базовый класс, от 
которого происходит конкретизация. Второй шаблонный параметр необходим, по- 
скольку, как показано на рис. 3.5, код, определенный пользователем, теперь включа- 
ется в середину иерархии классов, а не только в его корни (как это было в классе беп- 
зсасхегніегагсНу). 


4 Реализация не обязана использовать виртуальные таблиць, но большинство программи- 
стов все же применяют их. Описание виртуальных таблиц дано в работе ірртап (1994). 
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Напишем рекурсивный шаблонный класс бепііпеагнієгагспу. Он похож на 
класс Сбепѕсастегніегагсһу, но отношение наследования и шаблонный код, опреде- 
ленный пользователем, в нем обрабатываются иначе. 


тетр1ате 
< 
с1аѕ5 Ті151, 
тетр1ате <с1аѕ5 АтоптісТуре,с1аѕ5 Ва5е» с1аѕ5 піт, 
с1аѕ5 Воот = ЕмртуТуре // Класс ЕтрїуТуре описан в главе 2 
> 
сТа55 Сеп іпеагніегагсћһу; 


тетр1ате 
< 
сТаз5 Т1, 
с1аѕ5 Т2, 
тетрТате <с1аѕ55, с1аѕѕ> с1аѕѕ упіт, 
сТа55 Воот 
> 


с1аѕ5 бепі іпеагніегагсһу<Туре1151<т1, Т2>, Шпії, Воот» 
: риБ1іс Опії< Ті, Сепііпеагніегагсһћу<т2, Цпіт, Воої> > 


{ 

}; 

тетр1ате 

< 
сТа55 Т, 
тетр1ате <с1аѕ5, с1аѕѕ> с1аѕѕ Цпіт, 
с1а55 Коот 

> 


с1аѕѕ Сепііпеагніегагсһћу<түРЕШІ5Т_1(Т7), ОпіТ, ВКоот> 
: риБ1іс Опіт<т, воот> 


{ 

}; 

Этот код немного сложнее, чем у класса СсепѕсаїтегнНіегагсћһу, но структура ие- 
рархии класса сеп іпеагніегагсһу намного проще. Следуя пословице “лучше один 
раз увидеть, чем сто раз услышать” (“ітаре 15 мопһ 1,024 могӣѕ”), посмотрим на 
рис. 3.6, на котором изображена иерархия классов, порожденная следующим кодом. 


тетр1ате «сТа55 Т, с1аѕѕ Ваѕе> 
сТа55 ЕмепіснНнапаТег : риБ1іс Ваѕе 


( . 
рчЬ1іс: 
уігїіџа1 уоіа ОпЕуепеСт& обі, іпт еуептта); 
}; 
Туреде# Сеп і пеагніегагспу 
< 
ТҮРЕСІЅТ_3 (иіпдом, Виссоп, 5сгоїТваг), 
Емепінапд1ег 
> 
муЕмепїнапаег; 


В сочетании с классом Емептнапа1ег класс семі іпеагніегагсһу определяет линей- 
ную иерархию простого наследования. Каждый узел в этой иерархии определяет одну чис- 
то виртуальную функцию, как это предусмотрено для класса Еуепїнапд1ег. Следователь- 
но, в классе ЕмепіНапд1ег определены три виртуальные функции, как и требовалось. 
Класс бепіі пеагніегагсйу выдвигает новое требование к своему шаблонному 
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параметру: класс упі є (в нашем примере — класс Еуепінапа1ег) должен получать вто- 
рой шаблонный параметр и наследовать его свойства. В качестве компенсации класс беп- 
+1 пеагніегагспу выполняет сложную работу по генерации иерархии классов. 


ЕтріуТуре 


Д 


ЕхепіНапаіег<5сгоі1Ваг,ЕтрїуТуре> 


ОпЕуелі(зсі : Ѕсго!Ваг&, еуепіа : іп!) 
Д 


СепШіпеагНіегагсһу<ТҮРЕЦТ 1(8сгої|Ваг), ЕхепіНапаївг» 


ЕуепНапаіег<Вийоп, бепіпеагНівгагспусТУРЕЦІЯТ, 1(5сго!!Ваг), ЕмепіНападївт»» 


ОпЕмеп Ып : Вийоп&, емеліїй : ілі) 
Д 


СепИпеагНегагсНу<ТУРЕН$Т2(ВиНоп, Ѕсго!іВаг),ЕмепіНапаіег> 


Емем\Напег<УИптдо\, СепипеагНіегагсћу<ТҮРЕШ5Т2(Виїоп, 5сго!Ваг),ЕмепіНапаіег>> 


ОпЕмепмпа : Мпаом&, емепіа : іп?) 
А 


"МИВое\Еует! Нап ег 


Рис. 3.6. Иерархия классов, порожденная шаблонным классом Соепі.іпеагНіегагспу 


Классы Сепѕсаїтегніегагсһу и Сепі і пеагНніегагсну прекрасно работают в тан- 
деме. В большинстве случаев интерфейс можно генерировать с помощью класса сеп- 
Ѕсаїтсегніегагсһу, а реализацию — с помошью класса Сеп. і пеагніегагспу. Кон- 
кретные примеры использования этих двух генераторов приводятся в главах 9 и 10. 


3.14. Резюме 


Списки типов представляют собой важный метод обобщенного программирования. 
Они предоставляют создателям библиотек новые возможности: выражать и манипули- 
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ровать неограниченно большими наборами типов, генерировать структуры данных и 
код на основе этих коллекций и т.д. 

На этапе компиляции к спискам типов можно применять большинство элементар- 
ных функций, предусмотренных для обычных списков: добавлять, удалять и заменять 
элементы, удалять дубликаты, обращаться к элементам, осуществлять их поиск и даже 
выполнять их частичное упорядочение. Код, реализующий манипуляции со списками 
типов, ограничен чисто функциональным стилем, поскольку на этапе компиляции не 
существует изменяемых величин -- типы и статические константы, будучи однажды 
определенными, уже никогда не изменяются. По этой причине большинство опера- 
ций над списками типов основано на рекурсивных шаблонах и сопоставлении образ- 
цов с помошью частичной шаблонной специализации. 

Списки типов полезны, когда приходится писать один и тот же код — декларатив- 
ный или императивный — для каждого отдельного типа. Они позволяют абстрагиро- 
вать и обобщать сущности, которые невозможно абстрагировать и обобщать с помо- 
щью других приемов программирования. По этой причине списки типов представля- 
ют собой средство для создания совершенно новых идиом и реализаций библиотек, 
как мы увидим в главах 9 и 10. 

Библиотека Го содержит два мощных примитива для автоматической генерации 
иерархий классов: шаблонные классы Сепѕсаїтегніегагсһу и Сепі іпеагніегагсћу. 
Они генерируют две основные структуры классов: распределенную (см. рис. 3.2) и 
линейную (см. рис. 3.6). Линейная иерархия классов наиболее эффективна с точки 
зрения размера. Распределенная иерархия классов обладает полезным свойством: все 
конкретизации шаблона, определенного пользователем (передаваемого в качестве ар- 
гумента классу сепзсаттегн1егагспу), представляют собой корни финального класса, 
как показано на рис. 3.2. 


3.15. Краткое описание класса Туреїїізі 


е Заголовочный файл: туре115ѕ+.һ. 
• Все сущности класса находятся в пространстве имен г оКі: : ть. 
• Определен шаблонный класс Туре1151<неаа, Та11>. 


• Создание списка типов: определены макросы от ТУРЕЕТ$Т_1 до ТУРЕЕТЗТ..50. 
Количество принимаемых ими параметров указано в их имени. 


• Пользователь может повысить верхний предел макросов (50). 
#аеҒіпе ТУРЕЕТ$Т_51(т1, повторять вплоть до т51) \ 
ТҮРЕШІЅТ (Т1, ТҮРЕШІЅТ (Т2, повторять вплоть до т51)» 


• По соглашению первым элементом списков типов всегда является простой тип 
(не список типов), а хвост может быть либо списком типов, либо классом 
ми11туре. 


• В заголовочном файле определен набор примитивов, оперирующих со списка- 
ми типов. По соглашению все эти примитивы возвращают результат в виде оп- 
ределения вложенного (внутреннего) открытого типа под названием Везиї г. 
Если результатом работы примитива является значение, оно имеет имя уа1ие. 


® Примитивы описаны в табл. 3.1. 


• Краткое описание шаблонного класса сепзсатхегн1егагсВу: 
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тетрТафе «сТа55 ТЕЛ5%, сетрТабе «сТа55» сТа55 піс» 

с1аѕ5 бепзсасегнТегагсву; 

Шаблонньй класс бепѕсаёёегніегагсһу порождает иерархию, конкретизи- 
руюшую класс цпіє для каждого типа, указанного в списке типов ТЕЛ5Е. Кон- 
кретизация класса бепбсаттегн1егагсйу прямо или косвенно наследует свой- 
’ ства класса упії<т> для каждого типа Т из списка типов ТЕТ 51. 


Структура иерархии, порожденной классом беп5сассегніегагсНну, изображена 
на рис. 3.2. 


Краткое описание шаблонного класса Сеп іпеагніегагсћу: 

Тетр1ате <с1аѕ5 тіі5ѕ1, тетр1афе <сЛ1аѕ5, с1аѕѕ> с1аѕ5 Цпії»- 

с1аѕѕ Сбепііпеагніегагсћһу; 

Шаблонный класс Сепііпеагніегагсһу порождает линейную иерархию, изо- 
браженную на рис. 3.6. 


Шаблонный класс бепі іпеагніегагсну конкретизирует класс ипіт, передавая 
каждый тип из списка типов ТЕ15т в качестве первого шаблонного параметра 
этого класса. Обратите внимание: класс уп1т должен создаваться на основе 
второго шаблонного параметра с помощью открытого наследования. 


Перегруженные функции Ғіе1а обеспечивают доступ к узлам иерархии по типу 
и по индексу. 
Функция Е1е14<туре> (обі) возвращает ссылку на конкретизацию класса упії, 
соответствующую указанному типу туре. 

Функция ғіе1ӣ<іпӣех> (о6ј) возвращает ссылку на конкретизацию класса 


упіс, соответствующую типу, позиция которого в списке типов задается цело- 
численной константой 1пдех. 


Таблица 3.1. Статические алгоритмы работы со списками типов 


Имя примитива 
Гепдїћ<тііѕ1> 
Ттуредт<тііѕ1, 1їйх> 


туредїМопѕі гісї<Тіі51, їх» 


ІпдехоЁ<тііѕї, т> 
Аррепаӣ<тііѕт, т> 
Егаѕе<тііѕт, Т» 


Егаѕед11<ті1іѕ1, т> 


Глава 3. Списки типов 


Описание примитива 


Вычисляет длину списка типов т1151 


Возвращает тип, занимающий заданную позицию в 
списке типов ТЕТ$Т (считая от нуля). Если индекс 
больше длины списка или равен ей, возникает 
ошибка компиляции 


Возврашает тип, занимающий заданную позицию в 
списке типов ТЕЛ $1 (считая от нуля). Если индекс 
больше длины списка или равен ей, возвращается тп 
ми туре 


Возврашает инлекс первого вхождения типа Т в список 
тііѕт. Если тип не найден, возвращает число —1 


Добавляет в список ТЕЛ $ новый тип или список 
типов 


Удаляет первое вхождение в список ТЕ15* типа Т 
(если оно есть) 


Удаляет все вхождения в список Т1151 типа Т (если 
они есть) 
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Окончание табл. 3.1 


Имя примитива 
морир1ісатеѕ<т 151, Т> 
Аер1асе<т 151, Т> 


вер1асед] ]<ТтЕ1$%, Т> 


Ммо5 Оегімедстціз5с, Т> 


регімеатоЕгопі<Т 151, Т> 


Описание примитива 


Удаляет из списка Т115т все дубликаты 


Заменяет первое вхождение в список ТІ 1515 типа т 
(если оно есть) типом О 


Заменяет все вхождения в список ТЕТ 5 типа Т (если 
они есть) типом | 


Определяет наиболее глубоко вложенный тип, 
производный от типа Т. Если такого типа нет, 
возвращается тип Т 


Передвигает наиболее глубоко вложенные 
производные типы в голову списка типов Т1151 
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РАЗМЕЩЕНИЕ В ПАМЯТИ 
НЕБОЛЬШИХ ОБЪЕКТОВ 


В этой главе обсуждаются вопросы разработки и реализации механизма быстрого 
распределения памяти (аПосаїог) для небольших объектов. Использование таких рас- 
пределителей позволяет компенсировать дополнительные затраты ресурсов, происхо- 
дящие при динамическом размещении объектов. 

В разных местах библиотеки ГоК! используются очень маленькие объекты — их 
размер может не превышать нескольких байтов. В главе 5, посвященной обобщенным 
функторам, и главе 7, описывающей интеллектуальные указатели, маленькие объекты 
используются очень широко. По разным причинам, среди которых наиболее важной 
является их полиморфное поведение, эти маленькие объекты нельзя хранить в стеке. 

Для работы с динамической памятью в языке С++ есть два основных инструмен- 
та —- операторы пем и деЛеѓе. Проблема заключается в том, что эти операторы уни- 
версальны и неэффективно работают при динамическом размещении маленьких объ- 
ектов. Чтобы проиллюстрировать, насколько плохо они работают с маленькими объ- 
ектами, заметим, что некоторые стандартные распределители динамической памяти 
иногда работают на порядок медленнее и занимают в два раза больше памяти, чем 
распределители, описанные в этой главе. 

“Источник всех бед — ранняя оптимизация”, — заявил Дональд Кнут (Оопаіа Кий). 
С другой стороны, Лен Латтанци (Геп І абаплі) утверждает, что “поздняя пессимизация не 
приводит ни к чему хорошему”. Пессимизация только на один порядок во время выпол- 
нения программы таких основных объектов, как функторы, интеллектуальные указатели 
или строки, легко может угробить весь проекг. (“Пессимизация” — генерирование про- 
граммы, которая заведомо хуже ее оптимизированного варианта. — Прим. ред.) Выгоды, 
которые приносит дешевое и быстрое динамическое распределение памяти для маленьких 
объектов, могут быть огромными, поскольку она позволяет применять совершенные тех- 
нологии, не опасаясь значительных потерь производительности. Эти рассуждения являют- 
ся достаточно сильным побудительным мотивом для разработки способов оптимального 
размешения маленьких объектов в динамической памяти. 

Авторы многих книг, посвященных языку С++, например, Саттер (Ѕийег, 2000) и Мей- 
ерс (Меуегѕ, 1998а), упоминают о полезности разработки своих собственных специализи- 
рованных средств распределения памяти. Мейерс, описав какую-либо реализацию, остав- 
ляет некоторые детали “в виде упражнения для самостоятельной работы”, а Саттер отсы- 
лает читателей к “учебникам по С++ или программированию вообще”. Издание, которое 
вы держите в руках, не претендует на то, чтобы стать вашей настольной книгой. Однако в 


этой главе мы опустимся на уровень “железа” и реализуем свой собственный распредели- 
тель памяти в соответствии со стандартом языка С++ в мельчайших деталях. 

В этой главе описаны нюансы, связанные с настройкой механизмов распределения 
памяти. В ней рассмотрен сверхмощный механизм распределения памяти для ма- 
леньких объектов из библиотеки 101, рабочая лошалка для интеллектуальных указа- 
телей и обобщенных функторов. 


4.1. Стандартный механизм распределения 
динамической памяти 


По неизвестным причинам стандартный механизм распределения динамической памя- 
ти в языке С++ работает крайне медленно. Возможно, это связано с тем, что обычно он 
реализуется как тонкая оболочка вокруг распределителя динамической памяти языка С 
(та]11ос/геа1Тос/Ёгее), который неэффективно работает с небольшими участками памя- 
ти. В программах, написанных на языке С, обычно не применяются идиомы, позволяю- 
щие многократно выделять и освобождать небольшие участки памяти. Вместо этого про- 
граммы на языке С размещают в памяти средние и большие объекты (сотни и тысячи бай- 
тов), поэтому работа функций та11ос/Ёгее оптимизирована именно для них: 

Кроме этого, универсальность механизма распределения памяти в языке С++ ста- 
ла причиной крайней неэффективности использования памяти, выделяемой для ма- 
леньких объектов. Стандартный распределитель управляет кучей, что часто вынуждает 
его занимать дополнительную память. Обычно вспомогательная память занимает от 4 
до 32 байт для каждого блока, выделенного с помощью оператора пем. При выделе- 
нии блоков памяти размером 1024 байт дополнительные затраты незначительны (от 
0,4 % до 3 %). Однако, если возникает необходимость разместить в памяти объекты 
размером 8 байт, дополнительные затраты памяти составят от 50 % до 400 %. Эти 
числа достаточно велики, чтобы заставить программиста задуматься о том, как ему 
разместить в памяти большое количество маленьких объектов. 

В языке С++ динамическое распределение памяти имеет большое значение. Ди- 
намический полиморфизм часто ассоциируется именно с динамическим распределе- 
нием памяти. Такие стратегии, как “идиома Рітріе” (іће рітріе ійіот) (Ѕийег, 2000), 
изначально ориентируются на распределение динамической, а не статической памяти. 
(Название идиомы представляет собой аббревиатуру выражения "а Ройщег іо {ће 
ПМРГЕтещаНоп с1а55” — “указатель на класс реализации”. — Прим. ред.) 

Следовательно, низкая производительность стандартного механизма распределения 
памяти делает его камнем преткновения на пути создания эффективных программ на 
языке С++. Бывалые программисты на С++ инстинктивно избегают конструкций, 
ориентированных на использование динамической памяти, поскольку они по опыту 
знают о связанных с этим дополнительных затратах. Таким образом, у программистов 
возникает некий психологический барьер. 


4.2. Как работает стандартный механизм 
распределения динамической памяти 


Изучать тенденции, связанные с использованием памяти, как показал Кнут 
(Кпшћ, 1998), очень интересно. Он разработал много основных стратегий распределе- 
ния памяти, а после опубликования его работы их появилось еще больше. 
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Как работает стандартный механизм распределения памяти? Он управляет пулом 
байтов и может выделять из него участки памяти любого размера. В качестве вспо- 
могательной структуры может применяться простой блок управления. 


$ЕГИСЕ метСопсгоївТосК 


544: :512е_* 512е_; 
Боо1 ауаї1аБ1е_; 

$: 

Память, которой управляет структура МетСопїго1в1оск, располагается сразу за ним, а 
ее объем, выраженный в байтах, определяется переменной $1ге_. Вслед за этим уча- 
стком памяти располагается следующая структура мемсопїіго1в1оскК и т.д. 

Во время запуска программы в начале пула располагается только одна структура 
МетСопсгоївТосК, которая управляет всей памятью как одним большим участком. 
Это — корневой блок управления, который никогда никуда не перемещается. На 
рис. 4.1 показана схема распределения памяти для пула, имеющего объем 1 Мбайт, в 
момент запуска программы. 


ет | 


1048571 байт 


1048576 байт (1 Мбайт) 


Рис. 4.1. Карта распределения памяти в момент запуска программы 


При каждом запросе на выделение памяти выполняется линейный поиск подхо- 
дяшего блока, размер которого либо равен требуемому, либо превышает его. Порази- 
тельно, как много существует стратегий, позволяющих удовлетворить эти запросы, и 
как странно все они работают! Среди подходящих блоков памяти можно найти пер- 
вый, наилучший, наихудший и даже случайно выбранный. Как ни странно, наихуд- 
ший блок оказывается лучше наилучшего — как вам этот оксюморон?! 

Каждое удаление объекта из памяти влечет за собой новый линейный поиск блока, 
предшествующего удаляемому, и последующее выравнивание его размера. 

Как видим, эта стратегия не слишком эффективна с точки зрения затрат времени, од- 
нако дополнительные затраты памяти довольно малы — в каждом блоке нужно разместить 
две переменные типа 5і2е 5 и боо1 соответственно. Иногда можно даже сэкономить один 
бит на каждой переменной типа $12е_+, использовав его для. размещения переменной 
ауаі1аБ1е_. Сжатая структура МетСоп'єго1810СК имеет следующий вид. 


// код, зависящий от платформы и компилятора 
5сгисс Метсопего1В1осК 


5сд::5іге г $12е_ : 31; 
Боо] амаїТабТе : 1; 
$; 
Если в каждом объекте МетСопт го181осК хранить указатели на предыдущий и сле- 
дующий объекты этого типа, время, необходимое для освобождения памяти, может 
стать постоянным. Это происходит потому, что удаляемый блок связан со смежными 
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блоками и может их выравнивать соответствующим образом. Для этого необходима 
такая структура блока управления. 


5єгисє Метбопего] воск 


рос? амаїТабТе ; 
метсопіго1в1оск* ргеу; 
метСопісго181о0скК? пехі ; 

) 

На рис. 4.2 показано распределение пула памяти в виде дважды связанного списка 
блоков. Переменная-член ѕіғе_ больше не нужна, поскольку размер блока можно 
вычислить с помощью выражения +Н1$->пех+_ - їһіѕ. Дополнительные затраты па- 
мяти, связанные с необходимостью хранить два указателя и переменную типа Боо], 
по-прежнему существуют. (Как и ранее, можно прибегнуть к системно-зависимым 
трюкам и запаковать булевскую переменную в один из указателей.) · 


Е 


Рис. 4.2. Распределитель памяти с постоянным временем удаления 


Время, затрачиваемое этим распределителем памяти, по-прежнему прямо пропорцио- 
нально количеству блоков. Для того чтобы уменьшить эти затраты, существует много ис- 
кусных трюков, каждый из которых основан на собственной системе компромиссов. Ин- 
тересно, что совершенной стратегии распределения памяти до сих пор не существует; каж- 
дая из них использует дополнительную память, что снижает ее эффективность. 

Мы не ставим перед собой задачу усовершенствовать стандартный механизм рас- 
пределения памяти, а сосредоточимся на специализированных распределителях, кото- 
рые лучше всего работают с небольшими объектами. 


4.3. Распределитель памяти для небольших объектов 


Распределитель памяти для небольших объектов работает с четырехслойной струк- 
турой, показанной на рис. 4.3. Ее верхние слои используют функциональные возмож- 
ности, предоставляемые нижними слоями. На дне структуры расположен тип СһипкК. 
Каждый объект типа СпипКк содержит участок памяти (спипК), состоящий из целого 
числа блоков фиксированного размера, и управляет им. Объекты типа Сһипк позво- 
ляют выделять и освобождать блоки памяти. Если в объекте типа СпипК не осталось 
свободных блоков, функция распределения памяти вернет нуль. 

В следующем слое расположен класс Е1хедА1Тосатог. Объекты этого класса ис- 
пользуют участки памяти в качестве строительных блоков. Основное предназначение 
класса Ғіхеад11осатог — удовлетворять запросы на выделение памяти, объем кото- 
рой превышает размер участка. Для этого объекты класса ҒіхедА11осатог образовы- 
вают массив объектов типа Сһипк. Если поступил запрос на выделение памяти и все 
существующие участки памяти заняты, объект класса Ғіхейд1Лосатог создает новый 
объект типа СПипК и записывает его в массив. Затем он выполняет запрос на выделе- 
ние памяти, переадресовывая его этому объекту. 
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ЗтаїОбіесі * Предоставляет функциональные возможности на уровне объектов 
* Прозрачен — классы наследуют свойства только объектов класса Зта!Оеси 


ЅтаоЫАіосаїог * Позволяет размещать в памяти небольшие объекты разного размера 
* Конфигурацию параметров можно изменять 


ҒіхеаАосаїог Е 
Размещает объекты только одного фиксированного размера 


* Размещает объекты только одного фиксированного размера 
* Максимально возможное количество размещаемых объектов фиксировано 


Рис. 4.3. Многослойная структура распределителя памяти для небольших обьектов 


Класс ѕта11оЬјА11осатог выполняет общие функции, связанные с выделением и 
освобождением памяти. Объекты этого класса состоят из нескольких объектов класса 
ғіхейд11осатог, каждый из которых специализирован для выделения объектов опре- 
деленного размера. В зависимости от требуемого количества байтов объекты класса 
Ѕта1106јА11осатог направляют запрос одному из объектов класса Еїхедд1Тосатог 
или стандартному оператору ::орегатог пем, если запрашиваемый объем памяти 
слишком велик. 

На верхнем уровне расположен класс 5та110Біест, представляющий собой оболочку 
класса ҒіхедА1Лосатог. Он инкапсулирует все функциональные возможности, связанные 
с распределением динамической памяти, и предоставляет их другим классам. Класс $та1- 
106) ес* перегружает операторы пем и де1ете и передает их объектам класса 5та1 105541 - 
Тосатог. Таким образом, объекты, создаваемые программистом, могут наследовать функ- 
ции для работы с динамической памятью от класса $та1 106} еск. 

Кроме того, можно непосредственно использовать классы 5та110БіА1Тосатог и Еїх- 
еЧА1Тосатог. (Класс Сһипк слишком примитивен и ненадежен, поэтому он определяется в 
закрытом разделе класса ҒіхеаА11осатог.) Большей частью, однако, программы пользова- 
телей просто наследуют свойства базового класса 5та110Ь)А11осасог, приобретая функ- 
циональные возможности для распределения динамической памяти. Интерфейс этого 
класса достаточно прост. 


4.4. Класс Спипк 


Каждый объект класса СпипК содержит участок памяти, состоящий из фиксиро- 
ванного числа блоков, и управляет им. Размер и количество блоков указываются при 
создании объекта класса Ссһипк. Объекты типа СпипК позволяют выделять и освобож- 
дать блоки памяти. Если в объекте типа сһипк не осталось свободных блоков, функ- 
ция распределения памяти вернет нуль. 

Ниже приведено определение класса СПийк. 


// В классе нет закрытых полей — класс Сһипк представляет собой 
`// структуру старых простых данных (РТаїп 014 рата - РОр). 
// Структура определяется внутри класса Ғіхейд11осаїсог 
// и управляется только им. 
5ггист Спипк 
1 
уоїд Іпіс(5С:д'::5іхе с ЬТоск5іге, ипѕідпеа сһаг ЬТосК5); 
уоіа* діТосаге(5сд::5і2е С БТосК5і7се); 
уоїд реа11осате(уоіа* р, $14: :5іғе_ т ЬТосК51ге); 
ипѕідпеа сһаг* ррата_; 
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ипѕідпеа сһаг 
1 г5 сАМаї Таб ТевТосК ,, 
БТосКз5дмаїТарбТе ; 
у; 
Кроме указателя на управляемый участок памяти объект класса СпипК хранит сле- 
дующие целочисленные величины. 


» Переменная ГігзтАмаїТабТевТосК. хранит индекс первого доступного блока 
внутри порции памяти. й 


+ Переменная БТосК5АУаї ТабТе- представляет собой количество блоков, доступ- 
ных в данной порции памяти. 


Интерфейс класса Сһипк очень прост. Функция Іпії инициализирует объект класса 
Сһипк, а функция ве1еазе — освобождает занятую память. Функция А1Тосате выделяет 
блок памяти, а функция реа11осасе освобождает его. Функциям А11осате и реа11осате 
нужно передавать размер памяти, поскольку в самом объекте класса сһипкК эта величина не 
хранится, так как на верхних уровнях структуры размер блока неизвестен. Если бы в клас- 
се сһипк была предусмотрена переменная-член ЬТоск5іге , это было бы пустой тратой 
времени и памяти. Не забывайте, что мы находимся на самом дне структуры — здесь все 
имеет значение. По соображениям эффективности в классе Сһипк не определены ни кон- 
структоры, ни деструктор, ни оператор присваивания. Попытка определить семантику ко- 
пирования на этом уровне снизила бы эффективность работы верхних уровней структуры, 
на которых объекты класса СПипК хранятся внутри векторов. 

Структура СПипК демонстрирует важные ограничения. Поскольку переменные 
ЬТосК5АмаїТабТте. и Ғігѕтдуаі1аБТев1оск_ имеют тип ипѕідпеа спаг, порция не 
может содержать больше 255 блоков (на компьютерах, где символы состоят из 8 бит). 
Как мы вскоре убедимся, это решение вполне удачно и позволяет избежать многих 
неприятностей. 

Перейдем теперь к более интересной теме. Блок может быть занят или свободен. Все, 
что необходимо сохранить, записывается в свободные блоки. В первом байте свободного 
блока хранится индекс следующего свободного блока. Поскольку первый доступный ин- 
декс хранится в переменной Рі гѕїАмаі1аБ\ев1оск_, мы получаем полноценный одно- 
связный список свободных блоков, не используя дополнительной памяти. 

В момент инициализации объект класса Сһипк выглядит, как показано на рис. 4.4. 
Код его инициализации приведен ниже. 


уоіа Спипк::Іпіс(5:д::5іге с ЬТосК5іге, ип5ідпед сһаг ЬТосК5) 
{ 


ррата_=пем ип5 ідпед сһаг (БТосК51ге * Боск]; 
ҒігѕтАУаіТаБ1евіоск_ = 0; 

ЬТоск5АмаїТабТе бек 

уп$1дпед спаг 1 = 0; 

уп5ідпед сһаг* р = ррата_; 

Рог С; 1 іс ЬТоск5; р += Б1оскѕіге) 

1 


) 


хро = ++1; 


) 


Этот односвязный список, встроенный в структуру данных, представляет собой 
большое достижение. Он позволяет быстро и эффективно находить свободный блок 
внутри порции без дополнительных затрат памяти, причем на размещение и удаление 
блока тратится постоянное время, что исключительно важно. 


104 Часть |. Методы 


‚..251 блок... 


Рис. 4.4. Объект класса Сһипк, состоящий из 255 блоков 
по 4 блока каждый 


Посмотрим теперь, почему количество блоков ограничено величиной, соответст- 
вующей максимальному значению переменной типа ипѕідпеа сһаг. Допустим, что 
мы используем переменную более широкого типа, например ипѕідпеа ѕһогт, кото- 
рая на многих компьютерах занимает 2 байт. В этом случае перед нами возникают две 
проблемы — большая и маленькая. 


• Мы не можем размещать блоки, размер которых меньше величины 
51гео#(ипѕідпеа 5НПогі), что очень неудобно, поскольку мы разрабатыва- 
ем механизм распределения памяти для небольших объектов. Это маленькая 
проблема. 


• Мы сталкиваемся с вопросами выравнивания участков памяти. Вообразите, что 
мы создали механизм распределения для 5-байтовых блоков. В этом случае 
приведение указателя, ссылающегося на 5-байтовый блок, к типу ипѕідпеа іпт 
приведет к непредсказуемым последствиям. Это большая проблема. 


Решить эти проблемы довольно просто — нужно использовать тип ипѕідпеа сһаг 
в качестве типа для “тайного индекса” ("5ісайі іпдех"). Символьный тип по опреде- 
лению имеет размер, равный 1 байт, поэтому никаких проблем, связанных с выравни- 
ванием участков памяти не возникает, поскольку даже указатель на отдельную ячейку 
памяти ссылается на переменную типа ипѕідпеа сНаг. 

Это приводит к ограничению максимального количества блоков в объекте класса 
срипК, поскольку в нем не может быть больше, чем ОМСНАВ, МАХ блоков (в большинстве 
систем эта величина равна 255). Это вполне приемлемо, даже если размер блока действи- 
тельно мал, например, от 1 до 4 байт. Это относится и к более крупным блокам, поскольку 
в любом случае объекты класса СпипК по определению должны быть маленькими. 

Функция распределения памяти извлекает блок, на который ссылается переменная 
Ріг5сдуУаї 1аб1ев]осК_, и устанавливает ее на следующий свободный блок — типич- 
ная операция над списками. 


\014* СПипкК::А1Тосате ($14: :$1хе_+ Б1оск$12те) 


1+ С!ЬТосКзАуалТаБЛе_) гетигп 0; 
ип5ідпед сһаг* рвези]1т = 

ррата_ + СҒі гѕтАМаі1аБ1ев1оск_ * БЛосК$1те); 
// присвоение переменной ЁігѕтАУаі1ар1ев1оск_ 
// указателя на следующий свободный блок 
11гзтдуа1 1а Лев1осК_ = *ркези]т; 
--БЛоскѕАМаі1аБ1е_; 
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гефиги рвези1т; 


Итак, функция СһипК: :АЛЛосаёе состоит из одной операции сравнения, одной 
операции доступа по индексу, двух операций вычитания, присваивания и оператора 
декрементации — вполне приемлемо. Еще более важно то, что в этой функции не 
выполняется операция поиска. На рис. 4.5 показано состояние объекта класса СпипК 
после выполнения первой операции распределения памяти. 


ЯгзбАуайаЫеВюск_: 0 


БіоскеАмаїабівє :254 |7 


... 251 блок... 


Рис. 4.5. Состояние объекта класса СПипК после выполнения 
первой операции распределения памяти. Занятая память 
выделена серым цветом 


Функция освобождения памяти работает в точности наоборот. Она возврашает 
блок в список свободных блоков и увеличивает значение переменной БЛосКзАуа11- 
аБ]1е_. Не забудьте о необходимости передавать размер блока в качестве параметра 
функции реа11осате, поскольку объекту класса СпипК он неизвестен. 


\014 сһипКк: : реа11осате (уо14* р, $14: :$12е_х ЬТосК517е) 


аз5егт(р >= ррата_); 
ипѕіспеа сһаг* тове]еазе = 5сасіс са5 «ип5ідпейд сһаг*> (р); 
// проверка выравнивания 
аѕѕегі((токе1еаѕе - ррата_) % Б1осК$1ге == 0); 
хровеТеа5е = 11г5тАуа1Таб1ев1осК_; 
Ріг5 ЕАУаі1аБ1еВ1оск_ = ѕ+а+іс_саѕ+<ипѕ ідпеа сНаг>( 
(тове1еаѕе - ррата_) / Боск$1те); 
// проверка усечения 
аззегт (1 гѕтАмаі1аБ1ев1оск_ == 
(токе]еазе ~ ррата_) / БЛосКк$12е); 
++Б1осКзАуа1 1а 1 е_; 


} 


Функция освобождения памяти небогата содержанием, однако в ней содержится 
довольно много диагностических высказываний (которые по-прежнему не перехваты- 
вают все ошибочные ситуации). Структура СпипК вполне соответствует традиционным 
механизмам распределения памяти, принятым в языках С и С++. Если вы передадите 
функции Сһипк: :беаї Тосате неверный указатель, приготовьтесь к худшему. 


4.5. Класс РіхеаАіїосаїог 


На следующем уровне механизма распределения памяти для небольших объектов 
находится класс ЕіхедА11осатог. Этот класс предназначен для распределения памяти 
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при работе с блоками фиксированного размера, причем этот размер не обязан соот- 
ветствовать размеру порции. 

Для этого объект класса Еіхеад11осатог образует вектор объектов типа СһипКк 
При поступлении запроса на распределение памяти объект класса Ғіхеад11осатог 
отыскивает подходящий объект класса СпипК. Если все порции заняты, объект класса 
Е1хедА1 1 осатог создает новый объект класса СПипк. Вот как выглядит эта часть опре- 
деления класса. 

с1а55 Еіхеад11осатог 


{ 
ргімате: 
5с:д::5іг2е є ЬТосК5іге,; 
ипѕідпеа сһаг питвТоск$_; 
хуредеї 57а: : местог<Ссһипк> СһипК5; 
Сһипкѕ спипК5 ; 
СПипК* а1ЛоссһимКк_; 
СһипК* деа1ТоссСһипк_; 

$; 

Чтобы ускорить работу, класс Ғіхейд11осатог не перебирает элементы вектора 
спипК5. в поисках подходящего участка памяти при каждом запросе. Вместо этого в 
объекте хранится указатель на последний объект класса сһипк, который использовался 
при распределении памяти (переменная а11оссһипк_). При поступлении нового запроса 
функция Р1іхеад11осасе сначала проверяет, достаточно ли памяти в порции, на кото- 
рую ссылается указатель а11оссһипк_. Если этот объект удовлетворяет требованиям за- 
проса, то используется именно он. Если нет, выполняется линейный поиск (и, возмож- 
но, в вектор сһипкѕ_ записывается новый объект класса СПипК). В любом случае указа- 
тель аїТосСпипк устанавливается на найденный или вновь созданный объект класса 
Сһипк. Такой подход повышает вероятность того, что в следующий раз распределение 
памяти будет выполнено быстро. Вот как выглядит код этого алгоритма. 


\014* Еіхеад11осатог: : АЛ1Лосате() 


1Ғ (а11оссһипк_ == 
а11оссһипк__->Б1осКкѕАМаі1аБ1е_ == 0) 


// В данном объекте памяти недостаточно. 
// Попробуйте найти другой. 
СһипКкѕ : :ітегатог 1 = спипк5. .редіпО; 
Ғог С; +=1) 


ЗР (1 == сһипкѕ__. епа()) 
{ 


// все объекты заполнены — добавляем новый. 
сНипК$_ . геѕегме (спипК$_.$12е()+1); 

Сһипк пемспипКк; 

пемснипК 101 (Б1осК51 2е_, питвТосК5 ); 
спипК5 .ри5п Баск(пемспипК); 

а11осспипК_ = фФспипКк5. .Ьаск О; 
деа11оссһипк_ = фФсбипк5 .раск О; 


Ьгеак; 
} 
1Е С(-»ьр'оск5АМаїТар'є > 0) 
{ 


// объект найден 
а1]осСВипК.. = &*1; 
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ргеак; 


} 


аѕѕегі (а1Л1оссһипк__ != 0); 
аѕѕегі СаїТосСпипКк -»рТоск5АМаїТабТе > 0); 
гетигп аТТоссСпипК -»АТТосасе (ЬТосКк51ге, ); 

) 

Придерживаясь этой стратегии, класс Еіхедд1Тосаїог удовлетворяет большинство 
запросов за одно и то же время. При этом могут возникать некоторые задержки, обу- 
словленные поиском и добавлением новых блоков. Иногда эта схема может работать 
неэффективно. Однако на практике такие случаи встречаются редко. Не забывайте, 
что у каждого механизма распределения памяти есть своя ахиллесова пята. 

Освобождение памяти — более сложная задача, поскольку определенная часть ин- 
формации отсутствует. У нас есть лишь указатель на освобождаемую область памяти, 
и нам неизвестно, какому именно объекту типа Сһипк он принадлежит. Мы можем 
просмотреть содержимое вектора сһипкѕ_, проверяя, лежит ли данный указатель в 
диапазоне от роата_ до ррата + Б1оскѕіге_ * питв1оскѕ_. Если да, то указатель 
следует передать функции-члену реа11осате соответствующего объекта класса сһипк. 
Очевидно, что этот поиск требует затрат времени. Несмотря на то что операция выде- 
ления памяти выполняется быстро, процедура удаления занимает линейное время. 
Итак, нужно как-то ускорить этот процесс. 

Для этого можно применить вспомогательный кэш (саспе тетогу). Когда пользователь 
освобождает блок, используя вызов Ғіхеад11осатог: :реа11осате (р), объект класса Ғіх- 
еад11осатог не передает указатель р обратно соответствующему объекту класса СПипк, а 
записывает указатель р во внутреннюю память — кэш, в котором хранятся свободные бло- 
ки. При поступлении нового запроса объект класса ЕіхедА | Тосатог сначала просматрива- 
ет кэш. Если он не пуст, объект извлекает из кэша последний доступный указатель и не- 
мелленно возврашает его обратно. Это очень быстрая операция. Только когда кэш опус- 
тошен, объект класса Ғіхедд11осатог вынужден выполнить стандартную процедуру 
распределения памяти для объекта класса сһипк. Эта многообещающая стратегия в неко- 
торых достаточно распространенных случаях работает плохо. 

При распределении памяти для небольших объектов возможны такие ситуации. 


Распределение памяти для большого массива данных. В памяти одновременно 
размешаєтся большое количество мелких объектов. Это происходит, например, 
при инициализации набора указателей на маленькие объекты. 


• Удаление в том же порядке. Большое количество мелких объектов удаляется в том 
же порядке, в котором они были размещены в памяти. Это происходит при разру- 
шении большинства контейнеров из стандартной библиотеки шаблонов ЭТИ. 


• Удаление в обратном порядке. Большое количество небольших объектов удаляет- 
ся в порядке, обратном порядку их размешения в памяти. Для программ, напи- 


1 Стандарт языка С++ не определяет порядок уничтожения объектов, содержащихся в стан- 
дартном контейнере. Следовательно, каждый программист, занимающийся реализацией языка, 
может выбирать этот порядок по своему усмотрению. Обычно контейнеры разрушаются с по- 
мощью простого прямого повторения. Однако в некоторых реализациях разработчики сочли 
“более естественным” уничтожать объекты в обратном порядке. В обоснование этого приводит- 
ся факт, что в языке С++ объекты разрушаются именно в обратном порядке. 
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санных на языке С++, это вполне естественная ситуация при вызове функций, 
работающих с небольшими объектами. Аргументы функции и временные пере- 
менные стека соответствуют именно этому случаю. 


е Произвольное размещение и удаление. Объекты создаются и удаляются без опре- 
деленного порядка. Это происходит, когда при выполнении программы время 
от времени возникает необходимость в небольших объектах. 


Стратегия кэширования очень хорошо соответствует ситуации, при каждой объек- 
ты размешаются и удаляются в произвольном порядке. Однако при размещении и 
удалении болыного массива данных кэширование оказывается бесполезным. Хуже 
того, оно замедляет процесс удаления объектов, поскольку каждый раз тратит допол- 
нительное время на очистку буфера.) 

Лучше всего применять стратегию удаления объектов, совпадаюшую со стратегией их 
размещения в памяти. Переменная-член Е1хедАТЛосатог: : їеа11оссһипк_ указывает на 
последний объект класса СпипК, который был использован для удаления из памяти. Как 
только поступает запрос на удаление, эта переменная проверяется первой. Затем, если она 
ссылается на неверный объект типа СһипКк, функция реа11осате начинает линейный по- 
иск, обнаруживает требуемый объект и обновляет переменную 4еа1ТосСНипК_. 

Есть два важных приема, позволяющих ускорить работу функции реа11осате в 
указанных выше ситуациях. Во-первых, функция РреаїТосаге выполняет поиск под- 
ходящего объекта класса сһипк, начиная с окрестности указателя деа11оссһипк_. Это 
значит, что вектор сһипкѕ__ просматривается, начиная с переменной Яеа1 1оссһипКк_, а 
следующими проверяются итераторы, находящиеся выше и ниже. Это значительно 
повышает скорость удаления большого массива данных при любом порядке удаления 
(прямом или обратном). Во время размещения большого массива данных функция 
А1ТТосате добавляет объекты класса СпипК по порядку. Во время удаления либо указа- 
тель аеа11оссһипк_ сразу попадает в точку, либо правильный объект будет обнаружен 
на следующем шаге. 5 

Во втором трюке следует избегать крайних вариантов. Допустим, оба указателя а1- 
Тоссһипк_ и деаїТосСпипК, ссылаются на последний объект в векторе, и свободного 
места в этом множестве не осталось. Представьте, что произойдет, если будет выпол- 
няться следующий код. 


Фог С...) 
{ 


// некоторые интеллектуальные указатели используют свой 
// механизм распределения памяти для небольших объектов 
// (глава 7) 
Ѕмагїрїг р; 

... Используется указатель р ... 


} 

При каждом проходе цикла создается и уничтожается объект класса ЅмагїРїг. При 
создании объекта, поскольку памяти больше нет, функция ҒіхедА11оса- 
Тог::АЛ1Лосаїе создает новый объект класса СНипК и заносит его в вектор сһипкѕ_. 
При разрушении объекта функция ЕіхейА11осаїог: : реа11осате обнаруживает пус- 


2 Мне не удалось созлать разумную схему кэширования, которая одинаково хорошо работа- 
ла бы при удалении объектов в прямом и обратном порядке. Кэширование наносит вред либо 
одному, либо другому процессу. Поскольку обе ситуации часто встрсчаются в рсальных про- 
граммах, кэширование лучше не применять. 
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той блок и освобождает его. Эти затратные процедуры повторяются на каждой итера- 
ции цикла бог. 

Такая неэффективная работа недопустима. Следовательно, во время удаления объ- 
ект класса Сһипк должен освобожлаться, только если есть два пустых объекта этого 
класса. При наличии только одного пустого участка он быстро перемещается в конец 
вектора сһипкѕ_. Таким образом мы избегаем выполнения затратных операций мес- 
сог<СНийК> : :егазе, всегда удаляя лишь последний элемент. | 

Разумеется, могут возникнуть ситуации, при которых такой подход неприменим. 
При размещении в цикле вектора объектов класса тагЕРтг определенного размера 
может возникнуть та же проблема. Однако такие ситуации встречаются все реже и 
реже. Кроме того, как указывалось во введении, любой механизм распределения памя- 
ти в определенных ситуациях может оказаться хуже остальных. 

Выбранная стратегия удаления объектов хорошо соответствует произвольному по- 
рядку их создания. Даже если данные размещались без определенного порядка, про- 
граммы стремятся достичь определенной локальности (осаШу), каждый раз обращаясь 
к небольшой порции данных. Указатели а11оссћипК_ и Чеа]ТосспийК_ в этих ситуа- 
циях работают безукоризненно, поскольку при последующем размещении и удалении 
объектов эти указатели действуют как кэш. 

Итак, у нас есть класс ЕїхедА1Тосагог, достаточно эффективно удовлетворяющий 
запросы на распределение памяти фиксированного размера как с точки зрения затра- 
чиваемого времени, так и с точки зрения использования памяти. Класс ҒіхейА11оса- 
тог оптимизирован для работы с небольшими объектами. 


4.6. Класс ЗтаНОАНосафог 


Третий уровень нашей архитектуры механизма распределения памяти состоит из 
класса $та1 106] А]Тосатог, позволяющего размещать в памяти объекты любого раз- 
мера, объединяя в одно целое несколько объектов класса Е1хедА1Тосатог. Получив 
запрос на распределение памяти, объект класса Ѕма1106јА11осатог либо переадресует 
его наиболее подходящему объекту класса Ғіхедд11оса+ог, либо передаст его опера- 
тору ::орегаїог пем. 

Ниже приведено краткое описание класса Ѕта11оЬјА11осатог. Объяснения даются 
после кода. 


с1аѕѕ ѕта11оЬјА11осатог 


риБ1їс: 
ѕма11о6јА1ЛоОсатог( 
$4: :512е_$ сһипК512е, 
514::512е_+ тахорјесї512е); 
у014* А1Лосасе (514: :512е_ с пимвутез); 
уста Беа\Тосате(мот4* р, $14: :512е_ї 517е); 


ргімате: 
51а: :уесїог<ЕіхедӢд11осатог> роої ; 


$}; 

Конструктор получает два параметра, определяющих конфигурацию объекта класса 
$та11065]А1Тосатог. Параметр 512е задает размер участка памяти, принятый по 
умолчанию (длина каждого объекта класса СпипК, выраженная в байтах), а параметр 
тахоріест5іге задает максимально возможный размер объектов, которые еще могут 
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считаться “небольшими”. Объект класса Ѕта110ЬјА1Лосатог переадресовывает запро- 
сы на выделение блоков, размер которых превышает величину тахобјесї512е, непо- 
средственно оператору : : орегатог пем. 

Довольно необычно, что функция реа11осате получает размер объекта, подлежа- 
щего удалению, в качестве аргумента. Дело в том, что это позволяет ускорить процесс 
освобождения | памяти. В противном случае функция Ѕта11оЬјА11оса- 
сог: :реа11осате должна была бы искать среди всех объектов класса Рі хейд11осаїог 
тот, которому принадлежит данный указатель. Это слишком затратная процедура, по- 
этому объекту класса Ѕта11оЬјА1Лоса+тог нужно передавать размер удаляемого блока. 
Как мы увидим в следующей главе, эта задача изящно решается самим компилятором. 

Какое отображение существует между размером блока в объекте Еіхейд11осатог и 
вектором роої ? Иными словами, как по заданному размеру отыскать соответствую- 
щий объект класса Ғіхедд11осатог, который выполняет распределение памяти и ее 
освобождение? 

Простая и эффективная идея заключается в том, чтобы элемент роо1._[1] обраба- 
тывал объекты размера 1. Вектор роо1_ инициализируется с размером 
махобјесїѕіғе, а затем инициализируются все объекты класса Еіхейд11осаќог, со- 
держащиеся в нем. Если поступает запрос на выделение памяти размером питВуге5, 
объект класса зта110Б]А1Тосатог передает его либо элементу роо1_[пимвуте$] (эта 
операция имеет постоянное время выполнения), либо оператору : : орегатог пем. 

Однако это решение не настолько удачное, как кажется на первый взгляд. В кон- 
кретных ситуациях нам могут понадобиться распределители памяти только одного оп- 
ределенного размера, например 4 байт, и никакие другие объекты не нужны. В этом 
случае придется распределять память для 64 и большего количества элементов вектора 

‚ роо1._, хотя на самом деле используются только два элемента. 

Выравнивание размеров и заполнение пустот еше болыше снижают эффективное 
использование памяти. Например, многие компиляторы дополняют все типы, опреде- 
ленные пользователем, до размера, кратного заданному числу (2, 4 и тл.). Например, 
если компилятор дополняет все структуры до размера, кратного 4, то используется 
только 25% элементов вектора роо1_, остальные представляют собой балласт. 

Намного лучше пожертвовать скоростью просмотра, но сэкономить памятьз. Мы 
будем хранить объекты класса Е1хедА1Тосатог только для тех размеров памяти, кото- 
рые требуются хотя бы один раз. Таким образом, вектор роо1_ может содержать 
много объектов разного размера, не слишком увеличиваясь. Для того чтобы ускорить 
просмотр, вектор роо? хранится отсортированньм по размерам блоков 

Кроме того, ускорить просмотр можно с помощью стратегии, которая уже приме- 
нялась в классе Е1хедА1Тосатог. Объект класса $та1 106] АТТосатог хранит указатель 
на последний объект класса Еіхеад11осатог, использованный при освобождении па- 
мяти. Ниже приведен полный список переменных-членов класса 5та1 1А110сагог. 


сТаз55 5$та1106]АТТосахог 


ргімате: 
51а: :уестог<Еіхеад11осаїог> роо|_; 
Ғіхеад11осатог* ріаѕ+А11ос_; 


П 
П 
| 


3 Фактически в современных системах экономия памяти ведет к ускорению работы. Это 
происходит благодаря огромной разнице между скоростью работы основной памяти (большой и 
медленной) и кэш-памяти (маленькой и быстрой). 
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Еіхедйд11осатог* ргаѕтреа11ос_; 
; 

При поступлении запроса на выделение памяти сначала проверяется указатель 
реазА1Тос_. Если его размер не соответствует ожидаемому, функция 5та110БідАТ110- 
сатог: :А11осате выполняет бинарный поиск в массиве роо1_. Освобождение памяти 
осуществляется примерно так же. Единственное отличие заключается в том, что 
функция ѕта110ЬјА11осатог::А1Лосасе может закончить свою работу, вставив в 
массив роо!_ новый объект класса Ғіхейд11осатог. 

Как уже отмечалось при обсуждении класса ЕіхеаА11осатоғѓ, эта простая схема 
кэширования предназначена для многократного создания и удаления объектов за по- 
стоянное время. 


4.7. Трюк 


На последнем уровне нашей архитектуры расположен класс зта1106 ест, базовый 
класс, инкапсулирующий функциональные возможности, предоставленные классом 
5та1 106] А] Тосатог. 

Класс $та1 1063] ес+ перегружает операторы пем и деТете. Таким образом, при соз- 
дании объекта класса, производного от класса ѕта1106јест, в действие вступает пе- 
регрузка, направляющая запрос объекту класса Еіхеад11осатог. 

Определение класса $та11063]ест довольно простое, но интересное. 


с1аѕ5 $та110Б]есе 


риБ11с: 
ѕтаїіс моїй орегатог пем (51: :$17е_{ ѕ1іғе); 
зхасіс уоіа орегатог де1јете(уоїа* р, 514::51іге 8 $12е); 
уігтиа1 -5та11063ес*О {} 


; 

Класс 5таї ТОбіест выглядит вполне нормально, за исключением одной маленькой 
детали. Во многих книгах, посвященных языку С++, например, в учебнике Зийег 
(2000), говорится, что при перегрузке оператора де1ете его единственным аргументом 
должен быть указатель типа \014. 

В языке С++ есть одна лазейка, которая нас очень интересует. (Напомним, что мы 
разработали класс ѕта1106јА11осатог так, чтобы размер освобождаємого блока пере- 
давался как аргумент.) В стандартном варианте оператор йе1ете можно перегрузить 
двумя способами. Первый из них выглядит так. 


уоїд орегасог ае1еїе(уоій* р); 
Второй способ таков. | 
уоїд орегатог йеЛете (уоїа* р, $14: :5$12е_х 512е); 


Эта тема очень подробно изложена в книге 5ийег (2000). 

`Если используется первый способ, размер удаляемого блока памяти игнорируется. 
Однако этот размер нам очень нужен, поскольку его следует передать объекту класса 
эта 1 106] А1Тосатог. Следовательно, нам подходит лишь второй способ перегрузки. 

Как заставить компилятор автоматически определять размер блока? На первый 
взгляд кажется, что для этого понадобится дополнительная память для каждого объек- 
та, хотя именно этого мы и стремились избежать. 

Однако на самом деле никакой дополнительной памяти не требуется. Рассмотрим 
следующий код. 
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сТаз55 Ваѕе 


1пЕ а_[100]; 
риБ11с: 

уігтиа1 ~Ваѕе() {} 
}; 


сТаз55 Оегімеа : риб1іс Вазе 


іпе 6_[200]; 
риБ11с: 
мігтиаї -бегімедО {} 


ваѕе* р = пем регімей; 

ае1ете р; 
Объекты классов Ваѕе и регіуеа имеют разные размеры. Для того чтобы избежать 
лишних затрат памяти, связанных с необходимостью хранить размер фактического 
объекта, на который ссылается указатель р, компилятор прибегает к следующему трю- 
ку: он генерирует код, распознающий размер на лету. Этого можно достичь с помо- 
щью следующих четырех приемов. (Вообразите на несколько минут, что мы перево- 
плотились в разработчиков компилятора и способны творить чулеса, на которые не 
способны обычные программисты.) 


І. Деструктору передается булевский признак: “Вызывать/не вызывать оператор де- 
Тете после разрушения объекта”. Деструктор класса Ваѕе виртуален, поэтому в на- 
шем примере оператор де1ете р относится к правильному объекту класса Оегіхеа. 
В этом случае размер объекта известен уже на этапе компиляции — он равен 
512еоҒ(регіуей) — и компилятор просто передает эту константу оператору де] ете. 


2. Деструктор возвращает размер объекта. Мы можем сделать так (вель мы сами 
написали компилятор, не правда ли?), чтобы каждый деструктор после разруще- 
ния объекта возвращал величину 5 ігеоР(С1а552. Эта схема также вполне рабо- 
тоспособна, поскольку деструктор класса ваѕе виртуален. После его вызова сис- 
тема поддержки выполнения программ вызовет оператор йе1ете, передавая ему 
результат работы деструктора. 


3. Реализуется скрытая виртуальная функция-член, получающая размер объекта в 
качестве аргумента. Назовем ее _$12е(), например. В этом случае система под- 
держки выполнения программ вызовет эту функцию, сохранит результат ее ра- 
боты, уничтожит объект и вызовет оператор йеЛете. Такая реализация может 
показаться неэффективной, но ее преимущество заключается в том, что компи- 
лятор может использовать функцию _512е() и для других целей. 


4. Размер непосредственно хранится где-то в таблице виртуальных функций каж- 
дого класса. Это решение и гибко, и эффективно, но его нелегко реализовать. 


{Окончен бал, погасли свечи, и мы из разработчиков компилятора разжалованы в рядовые 
программисты.) Как видим, для того чтобы передать оператору ае1ете правильный размер 
блока, компилятор должен выполнить довольно много работы. Зачем же нам терять эту 
информацию и выполнять при каждом удалении объекта поиск, расходуя время? 

Ведь все так хорошо складывается! Объекту класса $та1ТА1Тосатог нужен размер 
удаляемого блока. Компилятор передает ему этот размер, а объект класса Ѕма110Ьјесї 
переадресовывает его объекту класса Е1хедд1Тосатог. 
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Большинство из перечисленных выше решений принято в предположении, что в 
классе Вазе определен виртуальный деструктор. Это лишний раз доказывает, насколь- 
ко важно делать деструкторы полиморфных классов виртуальными. Если этим требо- 
ванием пренебречь, удаление указателя типа Ваѕе, который на самом деле ссылается 
на объект производного класса, может привести к непредсказуемым результатам. В 
этом случае механизм распределения памяти в режиме отладки приведет к срабатыва- 
нию макросов аѕѕегт, а в режиме МОЕВИС просто вызовет крах программы. Каждый 
из нас согласится, что такое поведение можно считать “непредсказуемым”. 

Для того чтобы не заботиться об этом (и не проводить бессонные ночи, отлаживая 
программу, если вы вдруг забудете о том, что сказано выше), в классе $та1 106] ес+ 
определен виртуальный деструктор. Любой класс, производный от класса вазе, насле- 
дует его виртуальный деструктор. Это приводит нас к реализации класса $та1 106] ест. 

Во всем приложении нам нужен один-единственный объект класса Ѕта110ЬјА11о- 
сатог. Этот объект должен быть правильно создан и правильно разрушен, что само по 
себе трудно. К счастью, библиотека ЁоК! позволяет решить эту проблему с помощью шаб- 
лонного класса 5іпд1етопно1аег, описанного в главе 6. (Конечно, отсылать вас к сле- 
дующим главам досадно, но еще досаднее потерять возможность повторного использова- 
ния кода.) Пока можно рассматривать класс 5іпд1етопно1аег“ как механизм, позволяю- 
щий осуществлять управление единственным экземпляром класса. Если этот класс имеет 
имя х, шаблонный класс конкретизируется как 51пд1етоп<х. Затем, для того чтобы полу- 
чить доступ к единственному экземпляру этого класса, нужно вызвать функцию 5іпдТе- 
топ<х>; :Іпѕтапсе(). Шаблон проектирования 5іпдТетоп (Одиночка) описан в книге 
Сатта еї а]. (1995). 

Использование класса $1па1етоипно14ег позволяет чрезвычайно просто реализо- 
вать класс ѕта11оБјест. 

туредеї $1п9]етоп<5та110Ъ]А]Тосатог> МуА11ос; 

у014* Ѕта110оБјест: :орегатог пем(514::5і2е 5 $12е) 


І 


гетигп МУА11ос: :Іпѕїапсе () .А1Лосате (5іғе) ; 
уоїд $та1106]ест: : орегатог деЛете(моїа* р, ѕтаӣ::5іғе т 512е) 


МуА110ос: :1Іпѕтапсе 0 .Оеа11осате(р, $17е); 


4.8. Просто, сложно и снова просто 


Реализация класса Ѕта1106јест оказалась довольно простой. Однако на самом де- 
ле не все так просто — ведь остались нерешенными проблемы, связанные с многопо- 
точностью. Единственный объект класса Ѕта11А11осатог используется всеми экземп- 
лярами класса ѕта11објест. Если эти экземпляры принадлежат разным потокам, то 
объект класса ѕта110ЬјА11осатог придется распределять между ними. Как указано в 
приложении, в этом случае нужно предпринимать специальные меры. Кажется, нам 
придется пройтись по всем уровням нашей архитектуры, выделить критические опе- 
рации и добавить соответствующую блокировку. 

Однако многопоточность не является неразрешимой проблемой, поскольку в биб- 
лиотеке Гокі уже определены механизмы синхронизации объектов высокого уровня. 
Следуя поговорке “лучший способ повторного использования кода — его примене- 
ние”, включим заголовочный файл тһееааѕ.һ из библиотеки [окі и внесем в класс 
5та1 106] ес* следующие изменения (они выделены полужирным шрифтом). 
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хетрТасе <тетрТате <с1аѕ5 т> с1аѕѕ тһгеадіпдмоЯе1> 

с1аѕѕ зта11063есе : рибТіс тҺгеааіпдмоде1 <ѕта11оБјесе> 

{ 

$; 

Определения операторов пем и де1ете также подвергаются пластической операции. 


сетр1ате <тетр1ате <с1аѕѕ т> сТа55 тһгеааіламойе1> 
уо14* ѕта110оЬјесі<тһгеадіпдмойе1>: :орегатог пем(511::5і2е_1 512е) 


как и раньше 


цоск Лоск; 
геёигп МУА11ос: :Іпѕтапсе О .А1Лосате(ѕ12е); 


Ттетр1ате  <тетрТате <с1аѕ55 т> с1аѕ5 тһгеадіпдмойе1> 
уоіа ѕта11оБјесе<тһгеасіпдмоае1> : : орегатог е1ете (уоій* р, 
51а::51іхе 5 512е) 


Іоск Лоск; 
МУА1Тос: :Іпѕтапсе () .реа11осате (р, 51і2е); 


Вот и все! Все нижележащие уровни нашей реализации изменять не нужно — их 
функциональные возможности уже защищены блокировкой на верхнем уровне. 

Синглтоны и механизмы многопоточности, предусмотренные в библиотеке 10КІ, 
свидетельствуют о могуществе повторного использования кода. Каждый из этих во- 
просов — время жизни глобальной переменной и многопоточность — по-своему сло- 
жен. Преодолеть эти сложности на основе первого способа реализации класса ѕта1- 
Тобјест слишком трудно — хотя бы потому, что в классе ЕіхеддА11осасог приходится 
выполнять кэширование при инициализации одного и того же объекта для каждого 
потока в отдельности. | 


4.9. Применение 


В этом разделе показано, как использовать файл $та11063 .В в приложениях. 

Для того чтобы применить класс $та1106}, нужно задать соответствующие пара- 
метры конструктора класса ѕта11А11осатог: размер объекта класса СпипК и макси- 
мальный размер объекта, который может еще считаться небольшим. Что значит 
“небольшой” объект? Какие размеры считаются “небольшими”? 

Чтобы ответить на эти вопросы, вернемся к предназначению механизма распреде- 
ления памяти для небольших объектов. С его помощью мы хотели повысить эффек- 
тивность использования памяти и понизить затраты времени, преодолев ограничения, 
наложенные стандартным механизмом. 

Размеры дополнительной памяти, которая используется стандартным распредели- 
телем, сильно варьируются. Как-никак, стандартный механизм распределения памяти 
тоже может применять стратегии, изложенные в этой главе. В большинстве случае, 
однако, следует ожидать, что размер вспомогательной памяти на обычных машинах 
будет изменяться от 4 до 32 байт для каждого объекта. Для распределителя памяти, 
который для каждого объекта резервирует 16 байт дополнительной памяти, непроиз- 
водительные затраты составят 25 %; таким образом, объект размером 64 байт можно 
считать “небольшим”. 

С другой стороны, если объект класса ѕта11А11осатог размещает в памяти боль- 
шие объекты, в конце концов выделенной памяти окажется намного больше, чем 
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нужно (не забывайте, что класс Е1хедА1Тосатог стремится оставить в памяти хотя бы 
один объект класса СПипК, даже если все объекты удалены). 

Библиотека [о предоставляет выбор. В файле $та1106].В определены три символа 
препроцессора, приведенные в табл. 4.1. Все исходные файлы, входяшие в проект, следует 
компилировать, указав один и тот же символ препроцессора (или не задавая его вообще). 
Если этого не сделать, ничего смертельного не случится — просто будет создано больше 
объектов Е1хедА]] осатог, предназначенных для разных размеров. 

Параметры, предусмотренные по умолчанию, предназначены для машин с разум- 
ным объемом физической памяти. Если в директиве #аеҒіпе символы 
МАХ __5МАШ__ОВЈЕСТ_512Е или БЕРАУЕТ_СНУМК_$512Е определить равными нулю, то в 
заголовочном файле Ѕта1106ј.Һ будет применяться условная компиляция, которая 
просто использует обычные операторы ::орегафог пем и ::орегаїог 4е]ете, не 
прибегая к выделению вспомогательной памяти вообще. Интерфейс объектов остается 
прежним, но их функции становятся подставляемыми заглушками (іпіїпе 6$), что 
приводит к стандартному механизму распределения динамической памяти. 

Обычно шаблонный класс Ѕта1106јест имеет только один параметр. Для под- 
держки разных размеров участков памяти и небольших объектов этот класс получает 
еще два шаблонных параметра. По умолчанию ими являются константы РЕ- 
РАЧЕТ_СНУМК_5Т2Е и МАХ 5МАЇ | ОВОІЄСТ, 517Е соответственно. 

сетр1ате 

< 

тетрТате <с1аѕ5 т> 
с1аѕѕ Тпгеадіпдмоде? = рЕРАЦЕТ_ТНВЕАОТМС, 


ѕта::51ге с спипк5іге = РЕҒАЦТ__СНОМК_512Е, 
Ѕса::51і2е т тахѕта1106Ьјес512е = МАХ 5МАЩІ ОВОЕСТ, 5І7Е 


> 
с1аѕ5ѕ Ѕѕта110о6Бјест; 


Если просто написать ѕта110Ыј <>, вы получите класс, который может работать со 
стандартной моделью потоков. 


Таблица 4.1. Символы препроцессора, использованные в файле Ѕ$таноЫ.һ 


Символ Предназначение Значение по умолчанию 
РЕРАЦЕТ_СНУМК_51Т2Е Размер участка памяти (в байтах), 4096 
заданный по умолчанию _ 
МАХ У5МАТ І. ОВЗЕСТ. 512Е Максимальное значение, 64 
обрабатываемое классом 
эта] 106} А1Тосатог 
ОЕРАЦСТ_ТНВЕАРТМС Стандартная модель потоков, Наследуется от файла 
используемая в приложении. В ТЮгеа45 .П 


многопоточном приложении этот 
символ следует определять как 
СТаззкеме] тоска ]1е 


4.10. Резюме 


В некоторых идиомах языка С++ очень широко применяются небольшие объекты, 
расположенные в динамической памяти. Это происходит благодаря тому, что в языке 
С++ динамический полиморфизм (шийте роіутогріізт) тесно связан с распределе- 
нием динамической памяти и семантикой указателей и ссылок. Однако стандартные 
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механизмы распределения памяти (с помощью операторов ::орегафог пем и 
::орегагог деТеге) часто оптимизируются для работы с большими объектами, а не 
маленькими. Это делает стандартный механизм распределения памяти непригодным 
для работы с небольшими объектами, поскольку он медленно работает и неэффектив- 
но использует память. 

Для решения этой проблемы необходимо создать специальные механизмы распре- 
деления памяти для небольших объектов, настроенные на работу с маленькими бло- 
ками памяти (от десятков до сотен байтов). Эти механизмы объединяют элементарные 
блоки в более крупные участки (сһипкКѕ), стремясь минимизировать накладные расхо- 
ды памяти и времени. Система поддержки выполнения программ на языке С++ сама 
определяет размер освобождаемого блока. Эту информацию можно перехватить, про- 
сто применяя малоизвестную форму перегрузки оператора ае1ете. 

Может ли механизм распределения памяти для небольших объектов, предусмот- 
ренный в библиотеке ов, работать еще быстрее? Конечно, да. Этот механизм не вы- 
ходит за пределы стандарта языка С++. Как показано выше, такие проблемы, как вы- 
равнивание блоков памяти, решаются традиционным способом, что приводит к сни- 
жению эффективности его работы. И все же этот механизм работает достаточно 
быстро, просто и надежно, что гарантирует его платформную независимость. 


4.11. Краткое описание механизма распределения 
памяти для небольших объектов 


е Механизм, реализованный в библиотеке ГоК, имеет четыре уровня. Первый 
уровень состоит из закрытого типа Сһипк, предназначенного для организации 
памяти в виде участков (сһипкѕ), состоящих из блоков одинакового размера. На 
втором уровне. архитектуры находится класс Ғіхейд11осатог, в котором ис- 
пользуется вектор переменной длины, состояший из участков памяти. Этот 
класс предназначен для выполнения запросов на выделение динамической па- 
мяти. На третьем уровне расположен класс ѕта1106јА1Л1осатог, использующий 
несколько объектов класса Е1хеЧА1Тосатог. Это позволяет выделять память для 
объекта любого размера. Небольшие объекты размещаются в памяти с помо- 
щью объекта класса Ғіхеад11осаїог, а запросы на выделение больших участ- 
ков памяти переадресовываются стандартному оператору ::орегатог пем. По- 
следний, четвертый, уровень содержит шаблонный класс 5та110Біест, реали- 
зующий интерфейс объектов класса Ѕта110ЬјА11осатог. 


• Краткое описание шаблонного класса 5та110Біест выглядит так. 


хетрТате 
« 
тетрТасе <с1аѕ5 т> 
с1аѕ5 тһгеааіпдмойе1 = рЕРАЧЕТ_ТНВЕАОТМЮС, 
51::5і2е 1 сһипкѕіге = ОЕРАЦТ_СНУМК_$5Т2Е, 
51а::51ғ2е є тахѕта1106Ьјесї512е = МАХ, 5МАЦІ. ОВОІЕСТ, _512Е 


> 
сТа55 Ѕта110објесті 
риБ11с: з 
ЅТаїіс моїдх орегатог пем(54::517е Т 517е); 
5тасіс уоїд орегатог ЧеТете(мо14* р, 514::517е Т $12е); 
мігтца? ~Ѕта11оБјессО) 
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Функциональные возможности механизма распределения памяти для неболь- 
ших объектов можно унаследовать от конкретизации класса 5та110Ьіест. 
Шаблонньй класс Ѕта11оЬјес_ можно конкретизировать с параметрами, за- 
данными по умолчанию (бта110Б]ест<>), настроить его модель потоков или 
задать параметры выделяемой памяти. 


Если в нескольких потоках объекты создаются с помощью оператора пем, сле- 
дует использовать многопоточную модель, задав параметр тігеадіпомодеї. 
Информация об этой модели приведена в приложении. 


Значение константы ОЕЕАЦІ Т. СНЮМК. 512Е по умолчанию равно 4096. 
Значение константы МАХ 5МАЇ |. ОВІЕСТ 5І2Е по умолчанию равно 64. 


В директиве йдебіпе можно определить константы МАХ 5МАІІ, ОВОЕСТ, 5ІЛ7Е 
или ОЕРАИЕТ_СНУМК_512Е, или обе одновременно, заместив их значения, при- 
нятые по умолчанию. После расширения макрос распространяется на констан- 
ты типа $4: :$17е_+ (или совместимого типа). 


Если в директиве #аеҒіпе константы МАХ 5МАЦ | ОВЗЕСТ, 5178 или ОЕ- 
РБАЦІТ. СНУМК 5ІСЕ определить равными нулю, то в заголовочном файле 
Ѕта11оЬј.һ будет применяться условная компиляция, которая просто исполь- 
зует стандартный механизм распределения памяти. Интерфейс остается преж- 
ним. Это полезно, если нужно сравнить работу программы со специализиро- 
ванным механизмом распределения памяти и без него. 
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Компоненты 


ОБОБЩЕННЫЕ ФУНКТОРЫ 


Эта глава посвящена обобщенным функторам (репегаїігед ѓЁапс(огѕ) — мощной аб- 
стракции, позволяющей осуществлять несвязное взаимодействие между объектами 
(десоипріса іпісгобієсі соттипісайоп). Обобщенные функторы особенно полезны, ко- 
гда в объектах необходимо хранить запросы. Шаблон проектирования, описывающий 
инкапсулированные запросы, называется Соттапа (Сатта еї а!., 1995). 

Кратко говоря, обобщенный функтор — это любой вызов процедуры, позволенный в 
языке С+-, инкапсулированный в объекте первого класса, гарантирующем типовую безо- 
пасность (гурезаїе їїгѕ1-с1а55 обес®. (К первому классу относятся типы, обладающие 
всеми свойствами встроенных типов. Например, в языке С++ типы іпт и сһаг явля- 
ются типами первого класса. Объекты первого класса обладают полной семантикой 
значений. Их можно объявлять в любом месте программы, присваивать любым пере- 
менным, копировать и передавать по ссылке или по значению, а также возвращать в 
качестве значения функции. — Прим. ред.) 

Более детальное определение приводится ниже. 


• Обобщенный функтор инкапсулирует вызов любой процедуры, поскольку он 
получает указатели на простые функции, функции-члены, функторы и даже на 
другие обобщенные функторы, а также некоторые или все их аргументы. 


• Обобщенньй функтор гарантирует типовую безопасность, поскольку он никогда 
не передает аргументы неверного типа неправильным функциям. 


» Обобщенньй функтор является объектом, имеющим семантику значений, так как 
он полностью поддерживает копирование, присваивание и передачу параметров 
по значению. Обобщенный функтор можно свободно копировать, причем он не 
может содержать виртуальные функции-члены. 


Обобщенные функторы позволяют хранить вызовы процедур в виде значений, пе- 
редавать их как параметры и выполнять далеко от места их создания. Они представ- 
ляют собой усовершенствованный вариант указателей на функции. Существенное 
различие между указателями на функции и обобщенными функторами заключается в 
том, что функторы могут хранить состояние объекта и вызывать его функции-члены. 

В этой главе изложены следующие сведения. 


• Что такое шаблон проектирования Соттапа и как он связан с обобщенными 
функторами. 


• В каких ситуациях они могут принести пользу. 


• Внутреннее устройство различных функциональных сущностей в языке С++ и 
способы их инкапсуляции с помощью единообразного интерфейса. 


Как хранить вызов процедуры и некоторые или все ее аргументы внутри объек- 
та, передавать ее другим объектам и свободно ее вызывать. 


Как связывать между собой несколько отложенных вызовов и последовательно 
ИХ ВЫПОЛНЯТЬ. 


Как использовать мощный шаблонный класс Рипстог, реализующий описан- 
ные выше функциональные возможности. 


5.1. Шаблон Соттапа 


В классической книге о шаблонах проектирования (Сатта еї а!., 1995) утвержда- 
ется, что шаблон Соттапа предназначен для инкапсулирования запроса внутри объекта. 
Объект этого класса представляет собой часть работы, хранящуюся отдельно от своего 
исполнителя. Общая структура шаблона Соттапа представлена на рис. 5.1. 

Основной частью шаблона является сам класс Соттапа. Его основное предназна- 
чение — ослабить зависимость между двумя частями системы: вызывающим модулем 
и получателем. 

Типичная последовательность действий такова. 


1. 
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Приложение (клиент) создает объект класса СопсгетеСоттапа, передавая ему 
информацию, которой достаточно для выполнения задачи. Пунктирная линия 
на рис. 5.1 иллюстрирует тот факт, что клиент влияет на состояние объекта 
класса СопсгетеСоттап9. 


. Приложение передает интерфейс Соттапа объекта класса СопсгесеСоттапа вы- 


зывающему объекту, который сохраняет этот интерфейс. 


. Позднее вызывающий объект выбирает момент для начала действий и активи- 


зирует виртуальную функцию-член Ехесите из класса Соттапа. Механизм вир- 
туальных вызовов переадресует этот вызов объекту класса Сопсгесесоттапӣ, ко- 
торый отслеживает все детали. Объект класса Сопсгетесоттапа связывается с 
объектом класса Кесеїмег (это одно из его заданий) и использует его для вы- 
полнения реальной обработки данных, например, вызывая функцию-член Ас- 
хіоп. В противном случае объект класса СсопсгетеСоттапа может сам выполнить 
всю работу. В этом случае объект класса Весеїуег на рис. 5.1 не нужен. 


Весемег 


РЕА зе 


Рис. 5.1. Шаблон проектирования Соттапа 


СопсгеїеСопутапа 
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Вызывающий объект может свободно вызывать функцию Ехесуте. Еще более важ- 
но то, что в ходе выполнения программы в вызывающий объект можно встроить раз- 
ные действия, заменив объект класса Соттапа, который в нем хранится. 

Следует отметить два момента. Во-первых, вызывающий модуль не знает, как вы- 
полняется работа. Это отнюдь не ново — чтобы использовать алгоритм сортировки, 
не обязательно знать, как именно он реализован. Однако вызывающий объект не зна- 
ст даже, для какого вида обработки предназначен класс Соттапа. (Однако алгоритм 
сортировки обязан выполнять именно сортировку, а не что-то иное.) Вызывающий 
объект лишь вызывает функцию Ехесиїе из объекта класса Соттапа при наступлении 
определенного события. С другой стороны, получатель не обязан знать, что его функ- 
ция-член Ас\Топ была вызвана каким-то объектом. 

Таким образом, объект класса Соттапа гарантирует изоляцию вызывающего объек- 
та от получателя вызова. Они могут быть абсолютно взаимно невидимыми, общаясь 
лишь через объект класса Соттапа. Обычно связи между вызывающим объектом и по- 
лучателем вызова устанавливает объект класса Арр1ісаїіоп. Это значит, что для за- 
данного множества получателей можно использовать разные вызывающие модули, 
причем в заданный вызывающий модуль можно встраивать разных получателей — и 
все это происходит в условиях полной изоляции этих объектов. 

Во-вторых, посмотрите на шаблон Соттапа в перспективе. В обычных программи- 
стских задачах, когда нужно выполнить какое-то действие, при вызове задаются объ- 
ект, его функция-член и ее аргументы. 

міпдом.Ве5іге(0, 0, 200, 100); // изменение размеров окна 

Момент инициализации такого вызова в принципе невозможно отличить от мо- 
мента сбора его элементов в одно целое (объекта, процедуры и аргументов). Однако в 
шаблоне Соттапа вызывающий объект уже содержит элементы вызова, откладывая 
сам вызов на неопределенное время. Это иллюстрируется следующим примером. 

СомтапЧ геѕігестас 


м'іпдом, // Объект 
&м1п4о\м: : Ве$1 те, // Функция-член 
0, 0, 200, 100); // Аргументы 
// Позднее ... 
геѕігеста.  Ехесите 0; // изменение размера окна 


(Ниже мы остановимся на малоизвестной конструкции языка С++ &№іпӣом: : Вез1 ге.) 
В шаблоне Соттапа момент сбора информации об окружении, необходимой для обра- 
ботки данных, отличается от момента выполнения собственно обработки. В проме- 
жутке между этими двумя моментами программа хранит и передает запрос на обра- 
ботку в виде объекта. Если бы не существовала возможность отложить вызов, не было 
бы и самого шаблона Соттап4. С этой точки зрения само существование объекта 
класса Соттапа обусловлено возможностью откладывания вызова, поскольку запрос в 
это время нужно где-то хранить. 
Отсюда следуют два важных аспекта шаблона Соттапа. 


• Изоляция интерфейсов. Вызывающий объект изолирован от получателя вызова. 


•е Разделение времени. Объект класса Соттапа хранит готовый к выполнению от- 
ложенный запрос. 


Знание окружения также необходимо. Окружение (епупоптеп точки выполне- 
ния — это множество сущностей (переменных и функций), которые являются види- 
мыми из этой точки. В момент начала обработки необходимое окружение должно 
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быть доступным, в противном случае запуск невозможен. Объект класса Сопсгете- 
Соттапа может хранить часть нужной информации о своем окружении в виде своего 
состояния, а доступ к остальной информации получать во время вызова функции 
Ехесиїе. Чем больше информации об окружении хранится в объекте класса Соп- 
сгетесоттапа, тем более он независим. 

С точки зрения реализации можно идентифицировать две разновидности классов Соп- 
сгетеСоттапа. Некоторые из них просто поручают работу получателю, вызывая функцию- 
член объекта класса Весе1уег. Такие классы называются командами пересылки (Ќогмагаіпр 
соттапа$). Другие классы выполняют более сложную работу. Они также могут вызывать 
функции-члены других объектов, но имеют более сложную логику функционирования. 
Такие классы называются активными командами (асйуе соттап). 

Такая классификация команд позволяет очертить границы обобщенной реализа- 
ции. Активные команды нельзя описать раз и навсегда — их код по определению за- 
висит от конкретного приложения. В то же время на основе команд пересылки можно 
создавать шаблонные классы. Поскольку команды пересылки напоминают указатели 
на функции и похожи на функторы, мы будем называть их обобщенными функторами 
(репетайгед Гипстогз). 

Оставшаяся часть главы посвящена разработке шаблонного класса Ғипсїог, ин- 
капсулирующего любой объект, любую функцию-член этого объекта и любой набор 
аргументов, относящихся к этой функции. В момент активизации обобщенный функ- 
тор собирает все компоненты в одно целое, создавая вызов функции. 

Объект класса Ғипсїог может оказать неоценимую помощь при проектировании с 
использованием шаблона Соттапа. В реализациях, разработанных вручную, шаблон 
Соттапа масштабируется не слишком хорошо -- приходится писать много маленьких 
классов Соттап@ (по одному на каждую операцию: Стададџѕег, старе1етеџѕег, 
Стамоаї Руузег и т.д.), каждый из которых содержит тривиальную функцию-член 
Ехесиїе, просто вызывающую конкретную функцию-член некоторого объекта. Класс 
Ғипстог, обладающий возможностью вызывать любую функцию-член любого объекта, 
мог бы оказать в этом деле неоценимую помощь. 

В классе Ғипстог стоит реализовать и некоторые из активных команд, например, 
упорядочение нескольких последовательных операций. Тогда объект класса Ғистог 
мог бы собирать несколько операций и выполнять их по порядку. В книге Сатта еї 
аі. (1995) такие полезные объекты описаны под именем МасгоСоптапа. 


5.2. Шаблон Соттапа в реальном мире 


Применение шаблона Соттапа часто иллюстрируют на примере разработки окон- 
ного интерфейса. В хороших объектно-ориентированных специализированных систе- 
мах для разработки графического пользовательского интерфейса шаблон Соттапа в 
той или иной форме применяется уже многие годы. 

Создателям оконных интерфейсов необходим стандартный способ передачи пользова- 
тельских действий (например, щелчков мыши или нажатий клавиш) приложению. Когда 
пользователь щелкает на кнопке, выбирает пункт меню или делает что-нибудь подобное, 
оконная система должна уведомить об этом соответствующее приложение. С точки зрения 
оконной системы команда Ортіопѕ в меню Тоо15 не имеет никакого особого смысла. Это 
накладывает на приложение очень жесткие ограничения. Объект класса Соттапа позволяет 
эффективно изолировать приложение от оконного интерфейса, выступая в роли посред- 
ника, сообщающего приложению о действиях пользователя. 
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Например, в оконной системе в роли вызывающих объектов выступают элементы 
интерфейса (кнопки, пункты меню и т.п.), а получателем является объект, опреде- 
ляющий реакцию приложения на действия пользователя (например, диалоговое окно 
или само приложение). 

Объекты класса Соттапа представляют собой средство обшения между пользова- 
тельским интерфейсом и приложением. Как указывалось в предыдушем разделе, класс 
Соттапа обеспечивает удвоенную гибкость. Во-первых, в оконную систему можно 
встраивать новые элементы пользовательского интерфейса, не изменяя логику работы 
приложения. В таких случаях говорят, что программа имеет оболочку (ѕКіппаЫе), по- 
скольку новые элементы интерфейса можно добавлять, не касаясь самого приложе- 
ния. Оболочки не имеют никакой архитектуры — они только предоставляют места 
для объектов класса Соттапа и знают, как с ними взаимодействовать. Во-вторых, од- 
ни и те же элементы пользовательского интерфейса можно повторно использовать в 
разных приложениях. 


5.3. Вызываемые сущности в языке С++ 


Для того чтобы создать обобщенную реализацию команд пересылки, попытаемся 
описать связанные с ними понятия в терминах языка С++. 

Команда пересылки представляет собой обобщенный обратный вызов (репегайтед 
сађбаск). Обратный вызов — это указатель на функцию, который можно передавать и 
вызывать в любое время, как показано в следующем примере. 


моіа Еоо(); 
уоіа ваг(); 


1пс паїпО 


// Определяем указатель на функцию, не имеющую 

// параметров и возвращающую значение типа уоїд. 

// Инициализируем этот указатель адресом функции Ғоо 
у014 (*рғ) О = &ғоо; 


Ғоо 0; // непосредственный вызов функции Ғоо; 
ваг(); // непосредственный вызов функции Ваг; 
(+рғ) О; // вызов функции Ғоо через указатель рғ 
моїа (*рғ2) О = рғ; // Создаем копию указателя рғ 

рЕ = &ваг; // Устанавливаем указатель рғ 

// на функцию Ваг 

(*рЕ> 0); ` // вызов функции Ваг через указатель рЕ 
(*рЕ2) 0); // вызов функции Еоо через указатель рғ2 


} 


Между непосредственным вызовом функции ғоо и вызовом через указатель (тре)! 
есть одно существенное отличие. Во втором случае указатель можно копировать, где- 
то хранить и устанавливать на другую функцию, вызывая ее при необходимости. Сле- 
довательно, указатель на функцию очень похож на команду пересылки, в которой 
значительная часть работы хранится отдельно от объекта, выполняющего фактиче- 
скую обработку данных. 


1 Компилятор предлагает синтаксическое сокращение: выражение (*рЕ)() эквивалентно 
рғО. Однако выражение (*рЕ)() более наглядно отражает суть происходящего — указатель 
рЕ разыменовывается и к нему применяется оператор вызова функции (). 
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Действительно, обратный вызов — это способ использования шаблона Сопттапа в языке 
С. Например, система Х \УМтдо\ хранит такой обратный вызов для каждого пункта меню 
и каждого элемента интерфейса (м'дєег). Когда пользователь выполняет определенные 
действия (например, щелкает на кнопке), соответствующий компонент интерфейса акти- 
визирует обратный вызов, причем компонент не знает, что при этом происходит. 

Кроме простых обратных вызовов, в языке С++ есть еще много сушностей, под- 
держивающих оператор (). 


• Функции. 
• Указатели на функции. 


• Ссылки на функции (по существу, представляющие собой константные указа- 
тели на функции). 


» Функторы, т.е. объекты, в которых определен оператор 0. 
е Результат применения операторов .* и ->* к указателям на функции-члены. 


К каждой из указанных сущностей можно приписать пару круглых скобок, задать 
внутри них набор аргументов и выполнить какую-нибудь обработку данных. С други- 
ми сущностями в языке С++, кроме перечисленных выше, этого делать нельзя. 

Сущности, позволяющие применять оператор (©), называются вызываемыми 
(саПабіе). Цель этой главы — реализовать набор команд пересылки, способных хра- 
нить и передавать вызов любой вызываемой сушности?. Шаблонный класс Ейцпсіог 
инкапсулирует команды пересылки и обеспечивает единообразный интерфейс. 

Реализация должна учитывать три основных варианта: простые вызовы функций, 
вызовы функторов (включая вызовы объектов класса Ейпсіог, т.е. возможность пере- 
давать вызовы от одного объекта класса Ғипсїог другому) и вызовы функций-членов. 
Для этого следует создать абстрактный базовый класс и подкласс для каждого класса. 
На первый взгляд все это можно сделать с помошью средств языка С++. Однако, как 
только вы приступите к разработке программы, на вас обрушится ворох проблем. 


5.4. Скелет шаблонного класса Еипсіог 


Для класса Рипсфог обязательно следует проверить идиому “дескриптор-тело” 
(‘Кап е-Бо4у”), впервые предложенную в работе (Соріїеп, 1992). В главе 7 подробно 
объясняется, что в языке С++ голый указатель на полиморфный тип не имеет полно- 
ценной семантики из-за проблем, связанных с его принадлежностью. Для того чтобы 
снять ответственность за управление временем жизни объектов с клиентов класса 
Ғипстог, лучше всего наделить класс Ғипсёог семантикой значений (хорошо опреде- 
ленными операциями копирования и присваивания). Класс ғипстог имеет поли- 
морфную реализацию, но этот факт скрыт внутри него. Назовем реализацию базового 
класса именем ҒипстогІтр1. 

Отметим важную особенность: функция Соттапӣ: : Ехесифе шаблона Соттапа в 
языке С++ перевоплощаєтся в оператор (), определенный пользователем. Это еще 
один аргумент в пользу применения оператора (). Для программистов на языке С++ 


2 Обратите внимание на то, что мы ничего не говорим о типах. Мы могли бы просто ска- 
зать: “Типы, допускающие выполнение оператора (), называются вызываемыми сущностями”. 
Однако, хотя это кажется невероятным, в языке С++ есть сущности, не имеющие типа и в то 
же время позволяющие применять оператор (). 
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оператор вызова функции имеет точный смысл — “выполнить”. Однако намного 
важнее то, что этот оператор обеспечивает синтаксическое единообразие. Класс Ғипс- 
тог не только передает вызов вызываемой сущности, он и сам является таковой. В 
подобном случае объект класса Ғипстог может содержать другие объекты этого клас- 
са. С этого момента мы будем считать класс Ғипсїог частью множества вызываемых 
сущностей. Это позволит нам многие вещи делать единообразно. 

Проблемы возникнут, как только мы попытаемся определить оболочку класса 
ғипстог. Вначале она может выглядеть следующим образом. 


сТа55 ЕипсбоОГ 


рибііс: 

уоїд орегатог() О); 

/ другие функции-члень 
ргіуате: 

// реализация класса 


Первый вопрос: какой тип должно иметь значение, возвращаемое оператором ()? 
Должно ли оно иметь тип уоіа? В некоторых случаях может понадобиться вернуть 
что-то еще, например, значение типа роо] или $14: :5 сгіпд. Нет никаких причин от- 
казываться от возврата параметризованных значений. 

Для решения таких проблем преднезналенні шаблонные классы, позволяющие из- 
бежать лишних хлопот. 


тетр1ате «Сурепате Везиї стуре» 
сТа55 ЕипсбоГ 


риБ11с: 
Кези1ттуре орегатог() О); 
// Другие функции-члены 
ргімате: 
з // Реализация 


Это решение выглядит вполне приемлемо, хотя теперь у нас уже не один класс 
Ғипстог, а целое семейство. Это вполне разумно, поскольку функторы, возвращаю- 
щие строки, и функторы, возвращающие целые числа, имеют разные функциональ- 
ные возможности. 

Второй вопрос: должен ли оператор (), принадлежащий функтору, также получать 
аргументы? Может возникнуть необходимость передать объекту класса ғипстог некую 
информацию, которая была недоступна в момент его создания. Например, если щелч- 
ки мышью в окне пересылаются через функтор, вызывающий объект передает ин- 
формацию о координатах окна (известную только в момент вызова) объекту класса 
Еипстбог, вызывая его оператор (). 

Более того, в обобщенном программировании количество параметров не ограничивает- 
ся, причем они могут иметь любой тип. Таким образом, нет никаких причин накладывать 
ограничения ни на количество, ни на тип передаваемых функтору параметров. 

Отсюда следует, что каждый функтор определяется типом возвращаемого им значения 
и типами его аргументов. Для этого понадобится мошная языковая поддержка: перемен- 
ные шаблонные параметры в сочетании с переменными параметрами вызова функций. 

К сожалению, переменных шаблонных параметров в языке С++ просто нет. Вместо 
них предусмотрены функции с переменными аргументами (так же, как и в языке С). В 
языке С с их помошью выполняется значительная часть работы (при условии, что вы 
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очень осторожны), но для языка С++ этого недостаточно. Переменные аргументы под- 
держиваются с помощью эллипсисов (таких как ргіпєҒ или ѕсап#). Вызов функций 
ргіпєїб или 5сапії, когда спецификация формата не соответствует количеству и типу их 
аргументов, — весьма распространенная и опасная ошибка, иллюстрирующая недостатки 
эллипсисов. Механизм переменных параметров ненадежен, относится к низкому уровню и 
не соответствует объектной модели языка С++. Короче говоря, используя эллипсисы, вы 
остаетесь без типовой безопасности, объектной семантики (применение объектов, содер- 
жащих эллипсисы, приводит к непредсказуемым последствиям) и ссылочных типов. Для 
вызываемых функций недоступно даже количество их аргументов. Действительно, там, где 
есть эллипсисы, языку С++ делать нечего. 

В качестве альтернативы можно ограничить количество аргументов функтора про- 
извольным достаточно большим числом. Такая неопределенность — одна из самых 
неприятных проблем для программиста. Однако этот выбор можно сделать на основе 
экспериментальных наблюдений. В библиотеках (особенно старых) количество пара- 
метров функций не превышает 12. Установим предельное количество параметров рав- 
ным 15 и забудем об этой неприятности. 

Даже это не облегчило нашей участи. В языке С++ не допускается применение 
шаблонов, имеющих одинаковые имена, но разное количество параметров. Это зна- 
чит, что приведенный ниже фрагмент программы является неправильным. 

// Функтор без аргументов 


тетр1ате <турепате кеѕи1ттуре> 
с1аѕ5 рипстог 


// Функтор с одним аргументом 
тетр1ате <турепате Кези1ттуре, турепате Рагт1> 
с1аѕ5 РЕипсбог 


}; 
Называть шаблонные классы именами Ғипсїог1, Ғипсїог2 и так далее может ока- 
заться затруднительно. 

В главе 3 описаны списки Типов, позволяющие работать с коллекциями типов. 
Типы параметров функтора также образуют коллекцию, поэтому списки типов подой- 
дут нам идеально. Определение шаблонного класса Еипстог с помощью списков ти- 
пов приведено ниже. 

// Функтор, имеющий любое количество аргументов любого типа 


сетр1ате <турепате кези] мате, сТаз55 ТІ 150» 
сіа55 рипсъог 


Возможная конкретизация этого класса выглядит следующим образом. 


// Определяем функтор, получающий параметры типа їпс и Чоичб]1е 
// и возвращающий значение типа доче 
Ғипстог<аоибБ1е, ТУРЕЕТЗТ_2(1пт, доиріе)» муғипстог; 


Одним из достоинств этого подхода является возможность повторно использовать 
сущности, определенные списками типов, а не разрабатывать новые. 
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Как мы вскоре убедимся, списки типов хотя и полезны, но не решают всех про- 
блем. Мы по-прежнему вынуждены создавать отдельную реализацию функтора для 
каждого конкретного количества аргументов. В дальнейшем для простоты ограничим- 
ся двумя аргументами. Масштабировать программу для конкретного количества пара- 
метров (не больше 15) можно с помощью включения заголовочного файла Еипстог.Н. 

Полиморфный класс Рипстогіті, погруженный в класс Рипстог, имеет те же са- 
мые шаблонные параметры. 3 

хетрТасе <турепате В, сТа55 ТІ 150» 

сТа55 РипссогіІтрі; 

Класс Ецпссогітрі определяет полиморфный интерфейс, абстрагирующий вызов 
функции. Для каждого конкретного количества параметров определена явная специа- 
лизация класса ҒипсїогІтр1 (глава 2). В каждой специализации определена чисто 
виртуальная функция () для определенного количества и типов параметров. 


тетр1ате «Сурепате В» 
с1аѕ5 Рипстогітрі«в, Ми11Туре> 


{ : 
риБ11с: 

уігтиа1 к орегатог() О) = 0; 

У1Тгтиа] ҒипстогІтр1* С1опе () сопѕї = 0; 
уігтиа1 «Ейпсбогітрі О {} 


тетр1ате «Сурепате к, Сурепате РІ» 
с1аѕ5 Ейпсбогітрі«я, ТУРЕШІ5Т 1(РІ2)» 


риб1іс: 
у1гтиа] В орегатог() (РТ) = 0; 
У1гтиа] ҒипстогІтр1* С1опе() сопѕтї = 0; 
уТгтиа] «Рипсбогітрі О) {} 


тетр1ате <турепате В, Ссурепате РІ, турепате Р2> 
сТ1а55 РЕипссогітрі«В, ТУРЕЕТЗЬТ_2(Р1, Р2)> 


у 
рир1їс: 
мігтца? В орегатог(О) СР1, Р2) = 0; 
у1гтиа] ЕипссогІтр1* С1опе() соп${ = 0; 
мігсцаї ~ҒипссогІтр1 О) {} 
У; і 
Классы Ейпсбогітрі представляют собой частичные специализации исходного 
шаблонного класса ЕипсфогТтр1. Их свойства подробно описаны в главе 2. В нашем 
случае частичная шаблонная специализация позволяет определять разные версии 
класса Ғипстог1Ітр1 в зависимости от количества элементов в списке типов. 
Кроме оператора () в классе ҒипстогІтр1 определены две вспомогательные функ- 
ции-члены — СТопе и виртуальный деструктор. Функция Сіопе предназначена для 
создания полиморфной копии объекта класса Еипсфогттр]. (Детали полиморфного 


3 Использование ключевых слов Еурепате или с1аѕѕ для определения шаблонных пара- 
метров приводит к эквивалентным результатам. В книге по умолчанию при определении шаб- 
лонных параметров, которые могут относиться к элементарным типам (например іп), принято 
использовать ключевое слово Турепате, а ключевое слово с1аѕ5 применяется для шаблонных 
параметров, тип которых определяется пользователем. 
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клонирования изложены в главе 8.) Виртуальный деструктор позволяет уничтожать 
объекты классов, производных от класса Рипс®огттр], применяя оператор аеТете к 
указателю на объект класса Рипстогттр1. Важность этого деструктора подробно обсу- 
ждалась в главе 4. 

Классическая реализация класса Ғипстог приведена ниже. 


тетрТафе <турепате к, с1аз5 ТЕ1$%> 
сТа55 Ғипсїог 


риббіс: 
Ғипстог 0) ; 
Ғипстог(сопѕт ғипстсог&) ; 
Ғипстог& орегафог=(соп$Е Рипстог&) ; 
ехр1їсіт ғипстогС5та: :аито_ртг<ттр1> зрттр1); 


ргімате: 
// Определение тела функтора 
хуредеї ЕипстогІтр1<8&, ТЕ1$1т> Ітр1; 
ѕта: :аито ріг<ітр1> ѕрітр1_; \ 
$; 
В классе Ғипсїог интеллектуальный указатель на класс гипстогттр1<В, ТЕ1$%>, пред- 
ставляющий собой соответствующий тип тела функтора, хранится в виде закрытого члена. 
Для этого выбран стандартный интеллектуальный указатель 514: :ацто ріг. 

Приведенный выше код иллюстрирует наличие у класса ғипстог определенных ар- 
тефактов, демонстрирующих его семантику значений. К этим артефактам относятся 
конструктор по умолчанию, конструктор копирования и оператор присваивания. Яв- 
ный деструктор не нужен, поскольку интеллектуальный указатель аито_ртг автомати- 
чески освобождает все ресурсы. 

Кроме того, в классе Ғипссог определен “конструктор расширения”, предостав- 
ляющий классу ҒипстогІтр1 доступ к указателю аито_ртг. Конструктор расширения 
позволяет определять классы, производные от класса Рипсфогттр1, и непосредственно 
инициализировать класс Ғипсїог указателями на них. 

Почему аргументом конструктора расширения является итератор айсо ріг, а не 
обычный указатель? Создание объекта с помошью указателя аито_ргт явно свиде- 
тельствует о том, что объект класса Рипсбогітр! принадлежит классу Ғипсїог. Вызы- 
вая этот конструктор, пользователь класса Ғипсїог должен явно указать тип 
аито_ртг. Если он сделал это, значит, понимает, о чем идет речь.4 


4 Разумеется, это вовсе не обязательно. Однако это’ все же лучше, чем молча выбирать ОДИН 
вариант (копирование или владение). Хорошие библиотеки на языке С++ отличаются одной 
интересной особенностью: когда может возникнуть неопределенность, они позволяют пользова- 
телю устранять ее с помощью явного кода. С другой стороны, существуют библиотеки, непра- 
вильно использующие свойства языка С++, определенные по умолчанию (особенно преобразо- 
вания типов и владение указателями). Они предоставляют пользователям меньше возможностей 
для дополнительного программирования, но в качестве компенсации принимают сомнительные 
предположения и решения, облегчая работу пользователя. 
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5.5. Реализация оператора пересылки 
Еипсїог::орегаїог() 


В классе ғипстог необходим оператор О, который пересылал бы вызов оператору 
Ейпстогітрі : :орегатог(). Для этого можно было бы воспользоваться подходом, ко- 
торый мы применяли при разработке самого класса гипстогттр1, и создать группу 
частичных шаблонных специализаций, каждая из которых соответствует конкретному 
количеству параметров. Однако этот подход здесь не годится. В классе Ғипстог со- 
держится довольно больщое количество кода, и было бы неразумной тратой времени 
и памяти размножать его только для того, чтобы реализовать оператор (0. 

Однако сначала попробуем определить типы параметров. Тут нам на помощь при- 
дут списки типов. і 

тетр1ате <іурепате В, сТа55 Тііѕїі> 

с1аѕ5 Еипстог 


у турейеҒ Тії5с Рагті 155; 
туредеї турепате туредтмопѕтгіст<тііѕт, 0, Етртутуре>: : 
вези1е Рагті; 
хуредеї турепате Туредтмопѕтгіст<Тті 151, 1, Етртутуре>: : 
Вези]т Рагт2; 
как и раньше 

}; 

Класс ТуредтмопЅтгіст является шаблоном, обладающим доступом к типу по его 
позиции в списке типов. Если тип не найден, в качестве третьего шаблонного аргу- 
мента класса Туредтмопѕтгіст задается результат (т.е. внутренний класс Туредтмоп- 
5сгісс«...»::Ве5иЛг). В качестве третьего аргумента выбран класс ЕтртуТуре, яв- 
ляющийся, как следует из его названия, пустым. (Подробное описание класса 
Туредтмоп5тг1ст можно найти в главе 3, а описание класса ЕтрїуТуре — в главе 2.) 
Итак, тип Рагтм будет либо №м элементом списка типов, либо типом Епріутуре, ес- 
ли количество элементов списка типов меньше, чем М. 

Чтобы реализовать оператор (), воспользуемся интересным трюком. Определим 
все версии оператора () — для любого количества параметров — внутри определения 
класса Еипстог. 

хетрТасе <гурепате В, сТа55 Тіі51> 

сТа55 ЕипсбоГ 


1 
: как и раньше 
риБ11с: 
К орегатог() О 
гетигп (*5ртмр1_)О; 
} 
В орегатог() (Рагті рі) 
1 
гетигп (*5рттр1_)(р1); 
) 
В орегатог() (Рагті рі, Рагт2 р2) 
1 
гетигп ("5рітрі.2 (рі, р2); 
) 
| 
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В чем состоит трюк? Для данной конкретизации класса Рипстог правильной явля- 
ется только одна версия оператора (). Все остальные версии на этапе компиляции 
порождают сообщения об ошибках. Можно предположить, что класс Рипстог не будет 
скомпилирован вовсе, поскольку в каждой специализации класса ЕипстогІтр1 опре- 
делен только один оператор (), а не группа, как в классе гипстог. Трюк заключается 
в том, что в языке С++ функции-члены шаблонных классов не конкретизируются, 
пока они не вызваны. Пока не вызывается неправильный оператор (), компилятору все 
равно. При вызове перегруженного оператора (), не имеющего смысла, компилятор 
попытается сгенерировать его тело и обнаружит несоответствие. 

// Определяем функтор, получающий параметры типа іпї и доціїе, 

// и возвращающий значение типа доц Те. 

Ғипссог<аоиБ1е, ТУРЕЕТЗТ_2(1п%, доиБ1е)> турипсхог; 

// вызываем его. 

// генерируется тело оператора орегасог О (аоиБ1е, іпї). 

доч6]е геѕи1с = тувипссогі(4, 5.6); 

// Неверный вызов. 

доиБЛе гези]е = птувипссогО; //ошибка! 

// Оператор орегатог()() неверен, 

// потому что он не определен в классе 

// Рипссогітрі«доціТе, ТУРЕЕТ$Т_2(1п%, Чон 1е)>. 

Благодаря этому тонкому трюку класс Еипстог не обязательно частично инициали- 
зировать для нуля, одного, двух и больше параметров — это лишь приведет к дубли- 
рованию кода. Достаточно определить все версии и позволить компилятору генериро- 
вать только одну из них. 

Теперь все вспомогательные средства созданы, и можно приступать к определению 
конкретных классов, производных от класса Ейпсбсогітрі. 


5.6. Работа с функторами 


Начнем работать с функторами. Функторы представляют собой экземпляры клас- 
сов, в которых определен оператор (), как в классе гипстог (т.е. объект класса Ғипс- 
тог и сам является функтором). Следовательно, конструктор класса ғипстог, полу- 
чающий объект класса Ғипсїог в качестве параметра, является шаблоном, параметри- 
зованным типом этого функтора. 


тетр1ате <турепате в, с1аѕѕ тііѕт> 
сТа55 Рипсбог 


{ 
риБ1їс: 
Тетр1ате <с1аѕѕ Рип> 

Ғипстог Ссопѕт Рип& Тип); 


как и раньше ... 


; 

Для того чтобы реализовать этот конструктор, нам нужен простой шаблонный 
класс Ғипстоѓнапа1ек, производный от класса РипстогТир1<В, Тііѕї>. Этот класс 
хранит объект типа Еип и передает ему оператор (). Реализуя оператор 0), мы при- 
бегнем к описанному выше трюку. 

Чтобы избежать определения слишком большого количества параметров класса 
ЕипсстогнапаТег, сделаем щаблонньм параметром саму конкретизацию класса Ғипс- 
Тог. Этот единственный параметр содержит остальные, поскольку он предусматривает 
внутренний оператор суредеф. 
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тетр1ате <с1а$5 Рагептрипстог, турепате Еийп» 
сТа55 гипстогнапа]ег 
И риБ1іс ҒипстогІтр1 


< 
сурепате Рагепегипстог: : вези]1 етуре, 
сурепате Рагепскипстог::Рагтц 151 
> 
{ О 
руБ11с: 


ТуредеҒ турепате РагептЕипстог: : Кеѕи1 Туре вези]1ттуре; 


ҒипстоѓНапа1егСсопѕт Еип& Ғип) : Ғип_СҒим) {} 
ҒипстогнапаЛег* С1опе() соп5с 
{ гетигп пем ЕипстогнапаїегСћ15); } 


Кези]етуре орегатогО) О 
{ 


гехигп Тип О; 


Кеѕи1ттуре орегатог О Стурепате Рагептрипстог: :Рагт1 р1) 


гесиги Тип (рі); 


кези1+туре орегатог() (турепате РагепіРипсбог::Рагті рі, 
Турепате Рагептгипстог: : Рагт2 р2) 


гетигп Фип_(р1,р2); 


ргімате: 
Рип Фип_; 
}; 


Класс Рипстогнап Тег почти не отличается от класса ғипстог. Он переадресовы- 
вает запросы сохраняемой переменной-члену. Основное отличие заключается в том, 
что функтор хранится как значение, а не как указатель. Вот почему функторы явля- 
ются неполиморфными типами с обычной семантикой копирования. 

Обратите внимание на внутренние типы РагепеЕипстог: : Везу]ттуре, Рагепт- 
Ғипсїог: :Рагті и Рагептрипстог: : Рагт2. В классе РипстогНап Тег реализован про- 
стой конструктор, функция клонирования и несколько версий оператора О. Компи- 
лятор сам выберет правильный вариант. Если перегрузка оператора () выполнена не- 
верно, компилятор выдаст сообшение об ошибке. 

В реализации класса гипстогнаЧТег нет ничего необычного, но это вовсе не озна- 
чает, что .она тривиальна. В следующем разделе будет показано, какой универсально- 
стью обладает этот небольшой шаблонный класс. 

С помощью объявления класса РипстогНап ег легко написать шаблонный конст- 
руктор класса Ғипсіог. 

тетр1ате <№сурепате к, с1аѕѕ ТЕЛ$т> 

тетр1ате <іурепаме Еип> 


Ейипстог«В, ТЕ151>: : ҒЕипстог (сопѕт РИП& Тип) 
: эрттр1_(пем ЕипсіогнапдЛ1ег<Еипсёог, Ғип>СҒип)) ; 
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Здесь нет никакой ошибки. Два шаблонных параметра указаны правильно: выра- 
жение тетр]ахе <с1аѕ5 В, сТа55 Ті151> относится к классу Рипсіог, а к«еп- 
р1асе <турепате Ейп» является параметром конструктора. В стандарте языка такой 
код называется “шаблонным определением члена вне класса" (“оџі-оЁ-с1аѕѕ тетрег 
(етр!ае аейпійоп”). 

В теле конструктора переменная зрттр1_ устанавливается на новый объект типа 
РЕипссогнапаТїег, конкретизированный и проинициализированный соответствующими 
аргументами. 

Есть еще кое-что, о чем следовало бы упомянуть, кое-что, позволяющее лучше по- 
нять реализацию класса Ейпссогнапаїег. Обратите внимание на то, что при входе в 
тело конструктора класса Рипсфог полная информация о типах уже содержится в 
шаблонном параметре кип. При выходе из конструктора эта информация теряется, 
поскольку всем объектам класса Еипстог известен лишь указатель зрттр1_, ссылаю- 
щийся на базовый класс Еипссогітрі. Эта очевидная потеря информации весьма 
примечательна: конструктор знает тип и действует подобно фабрике, преобразующей 
этот тип в полиморфное поведение. Информация о типах сохраняется в динамиче- 
ском указателе на класс ҒипстогІтр1. 

Хотя мы написали лишь часть кода (просто несколько функций, состоящих из од- 
ной строки), уже можно кое-что проверить. 

// предположим, что файл Еипстог.ћ включен 

// в реализацию класса РЕипсіог 

#1пс1ийе "Еийпсбсог.Н" 

#іпс1иде «іо5сгеат» 

// для небольших программ на С++ можно применять 


// директиву иѕіпд 
и5іпд патезрасе 54; 


// определяем тестируемьй функтор 
$ЕГИСЕ Тез СРипсіог 


{ 
усій орегатог() пі 1, ЧоибЛе а) 
соиї << "Тезфгипсхог: : орегатог() С" << 1 
<<", " << а << ") са11еа. Мп"; 
} 
$; 
іпе таїп 0 
ТеѕтЕипстог +; 
РЕцпсбог«моїй, ТУРЕ|І5Т. 2(їпс, доціьбе)» ста СР»; 
ста(4, 4.5); 
} 


Эта маленькая программа выводит на печать следующую строку. 
тезхрипстог: :орегатсог() (4, 4.5) са11еа. 


Следовательно, МЫ ДОСТИГЛИ своей цели. Теперь можно идти дальше. 
5.7. Один пишем, два в уме 


Читая предыдущий раздел, не задавались ли вы вопросом: “Почему мы не начали с 
реализации простых указателей на обычные функции?”. Зачем мы перескочили сразу к 
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функторам, шаблонам и т.п.? Ответ прост — в настояшее время подлержка указателей на 
обычные функции уже реализована. Изменим немного нашу тестовую программу. 
яїіпсТиде "Рипсфог.И" 


#1пс1иде «іо5 сгеат» 
иѕіпд патезрасе 514; 


// Определяем тестируемую функцию 
уоїд теѕтғипстіоп (1пт 1, аоиБ1е а) 


соиї << "ТезтрипстТоп(" << 1 
т 


<<", " << а << ") са11еа. Мп"; 


} 
іпс мати 


Ейпстог«хумоїда, ТУРЕСТ$Т_2(1пт, аоиБ1е)> ста (ТезфгипсттТоп); 
// выведет на печать строку 

// "ТезсЕцпссіїоп(4, 4.5) са Теа." 

ста(4, 4.5); 


Объяснение этого приятного сюрприза кроется в способе вывода шаблонных парамет- 
ров. Когда компилятор обнаруживает класс Ғипсїог, созданный из функции ТеѕТҒипс- 
Топ, он вынужден проверить шаблонный конструктор. Затем компилятор конкретизирует 
шаблонный конструктор шаблонным аргументом моїй (&)(1пт, 4оиЛе), представляю- 
щим собой тип значения, возвращаемого функцией ТезфЕипс*1оп. Конструктор конкрети- 
зирует класс ЕцпстогНапаіТег«Еипстог«...», моіа (82 (пе, доцбТе)». Следовательно, 
переменная Тип. в классе ЕипстогНапаїег также имеет тип моїй (49 (їіпт, аоиБ1е). При 
вызове оператора ЕипссогнапаТегх...»: :орегатог О он передается функции Ғип_ О. Это 
вполне допустимая синтаксическая конструкция, означающая вызов функции с помощью 
указателя. Итак, класс ЕипстогНнап Тег поддерживает указатели на внешние функции по 
двум причинам: благодаря синтаксической схожести указателей на функции и функторов и 
особенностям механизма вывода типов в языке С++. 

Однако есть одна проблема. (У всех есть свои недостатки, не так ли?) При пере- 
грузке функции Теѕїғипсї1іоп (или любой другой функции, которая передается клас- 
су Ейпсбог«...») возникает неопределенность. Ее причина заключается в том, что 
при перегрузке функции ТеѕТЕипсї1іоп тип символа ТеѕТЕипсїіоп становится неоп- 
ределенным. Чтобы проиллюстрировать этот факт, поместим перегруженную версию 
функции Тезтрипст1Топ прямо перед функцией таіп. 

// объявление перегруженной функции ТеѕїҒисїіоп 

// Сопределение не обязательно) 

моіа ТезтрипсеТоп (Лит); 

Неожиданно компилятор сообщает, что не может распознать, какую из перегруженных 
версий функции Те5 сРипсбсіоп следует использовать. Поскольку есть две функции с име- 
нем ТезеРипс Топ, одного имени для идентификации функции недостаточно. 

В сушности, при перегрузке есть два способа идентифицировать конкретную 
функцию: с помощью инициализации (или присваивания) или с помощью приведе- 
ния типов. Проиллюстрируем оба метода. 


// Как и выше, функция Теѕтғипстіоп перегружена 
іп мати() 


// Для удобства используется оператор хуредеї 
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Хуредеї уоіа (*трғип) (іп, доче); 

// Способ 1: инициализация В 

трғип рғ = Тезфрипсе1оп; й 

Ейисбог«моїд, ТУРЕЕТЗЬТ_2(1п<, доцьбе)» 

стд1(4, 4.5); 

// Способ 2: приведение типов 

Еипстог<моіа, іпс, дӢоиб1е)> ста2( 
ѕтаїіс__саѕї<трғип»> (Те СРипссіоп)); // Все правильно! 

ста2 (4, 4.5); 

} 


Оба способа инициализации позволяют компилятору распознать требуемую вер- 


сию функции Теѕтғист1іоп, которая должна получать параметры типа іпт и доу Те, а 
возвращать — значение типа моїд. 


5.8. Преобразование типов аргументов 
и возвращаемого значения 


В идеале преобразование типов для функторов должно выполняться так же, как и 
при вызовах обычных функций. Тогда можно было бы написать примерно такой код. 


#іпс1иде <5тг1пд> 

#1пс]и4е «іо5сгеат» 
#1пс1иде "Еийпсбсог.Н" 
и5іпд патеѕрасе 54; 


// Аргументы игнорируются — в данном примере 
// они не представляют интереса 
соп$т сһаг* Тезфриис®Топ(аоч Ле, доиЬ1е) 


{ 
Ѕтаїтіс соп5с сНаг БиҒҒеғ[] = "Не110о, мог1а!"; 
// можно вернуть указатель на статический буфер 
гетигп Би Рег; 

} 


іпо маіп() 


РЕйпссог«5сгіпд ТУРЕЦІ5Т 2(їпс, іпс)» стаб(тез5 сЕйпсСіоп); 
// Должен выводить на печать строку "мога!" 
соит << стас10, 10).5и65%г(С7); 

} 

Несмотря на то что сигнатура фактической функции Теѕтғипстіоп немного отлича- 
ется (она получает два параметра типа доц Ле и возвращает константу типа сһаг*), ей 
можно поставить в соответствие функтор Ғипстог<51гіпд, ТУРЕЕТЗЬТ_2(1п&, 1п%)>. 
Предполагается, что это возможно, поскольку тип іп можно неявно преобразовать в 
тип доче, а значение типа соп5с сһаг* — в тип ѕїгіпа. Если класс Ейпсбог не под- 
держивает те же преобразования, что и язык С++, то такие жесткие ограничения следу- 
ет считать неоправданными. 

Для того чтобы удовлетворить новые требования, не нужно писать новый код. 
Приведенный выше пример компилируется и выполняется без проблем. Почему? Как 
и прежде, ответ следует искать в определении класса ғипстогнапа1ег. 

Посмотрим, что произойлет после конкретизации шаблона в привеленном выще 
примере. Функция 


5сгіпа Рипсхог<...>: :орегатог() Сіп і, іпо 1) 
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передается виртуальной функции 

з5сгіпд РипстогнайТег<...>: :орегатог() Сіпт 1, іпт 5) 
Реализация виртуальной функции выполняет вызов 

гегиги Тип (С, 7); 


Здесь функция Кип_ имеет тип сопѕї сНаг*(*)(донцБ]е, доиБ1е) и вычисляет зна- 
чение функции ТеѕїҒипсї1іоп. 

Когда компилятор обнаружит вызов функции Тип , он нормально его скомпилиру- 
ет, как если бы вы написали этот вызов собственноручно. Слово “нормально” означа- 
ет, что правила приведения типов применяются как обычно. Затем компилятор гене- 
рирует код, преобразовывающий переменные 1 и } в тип дои Те, а результат приво- 
дится к типу $19: :51гіпд. 

Универсальность и гибкость класса Еипстогнапаїег иллюстрирует мощь генера- 
ции кода. Синтаксическая замена аргументов шаблона соответствующими параметра-: 
ми позволяет оперировать с программой на уровне исходного текста. В отличие от: 
этого, мощь объектно-ориентированного программирования проявляется в позднем 
{после компиляции) связывании имен с их значениями. Таким образом, объектно- 
ориентированное программирование способствует повторному использованию кода в 
форме бинарных компонентов, в то время как обобщенное программирование поощ- 
ряет повторное использование исходного кода. Поскольку исходный код по определе- 
нию более информативен и находится на более высоком уровне, чем бинарный, 
обобщенное программирование позволяет создавать более сложные конструкции. Од- 
нако это происходит за счет замедления выполнения программы. Со стандартной 
библиотекой шаблонов невозможно работать так же, как с технологией СОВВА, и на- 
оборот. Эти две технологии дополняют друг друга. 

Теперь мы можем работать с функторами всех видов и обычными функциями, ис- 
пользуя один и тот же базовый код. В качестве вознаграждения мы получаем возмож- 
ность неявно преобразовывать тимы аргументов и возвращаемого значения. 


5.9. Указатели на функции-члены 


Указатели на функции-члены не часто встречаются в программистской практике, но 
иногда они оказываются очень полезными. Они аналогичны указателям на обычные 
функции, но при вызове функции-члена нужно передавать объект (помимо аргументов). 
Синтаксис и семантика указателей на функции-члены описывается следующим примером. 


#іпс1иае <1озтгеат> 
и5іпд патеѕрасе $14; 


с1а$$ раггот 


риб1іс: 
уоїд Еат 0) 


соиї << "ням, ням, ням ...\п"; 
} 
\014 5реакО 
{ 


сої << "Пиастры! Пиастры! \п"; 


> 


Глава 5. Обобщенные функторы 137 


тис маіпО) 


// Определяем тип: указатель на функцию-член 
// класса Раггох, не имеющую параметров и 

// возвращающую значение типа моїй 

уреде? усій (Раггоє: :* Трметгип) (); 


// Создаем объект указанного типа 

// и инициализируем его адресом функции Раггос: : Еат 
трметЕиуп рассімісу = &Раггої: :еат; 

// Создаем объект класса Раггот 

Раггос дегопіто; 

// ... м указатель на него 

Раггос* рбегопіто = ёдегопіто; 


// с помощью объекта вызываем функцию-член, 

// адрес которой хранится в указателе рАсїіуіту. 
// обратите внимание на оператор .* 

(дегопіто. "рассімі су) О); Р 


// делаем то же самое, но с помощью указателя 
Срсегопіто-» "рАССімі су) О; 

// изменяем действие 

рассімісу = &Раггот: : ѕреак; 


// Проснись, Джеронимо! 
(дегопіто  г«раАссімі су) О); 


) 
Приглядевшись внимательнее к указателям на функции-члень и двум связанньм с 
ними операторам -- .* и ->*, можно заметить странные особенности. В языке С++ 


не существует типа для результата работы функций дегопіто."рдссіміту и 
дегоп1то->*рдсету1еу. С обеими бинарными операциями все в порядке. Они воз- 
врашают нечто, к чему можно непосредственно применять оператор вызова функции, 
но это “нечто” не имеет типа. Результат выполнения операторов .* и ->* невозмож- 
но хранить ни в каком виде, хотя он представляет собой сущность, обеспечиваюшую 
связь между объектом и указателем на функцию-член. Эта связь выглядит очень не- 
прочной. Она возникает из небытия сразу после вызова операторов .* или ->*, суще- 
ствует довольно долго для того, чтобы к ней можно было применить оператор (©) и 
возвращается в обратно небытие. Больше с ней ничего сделать нельзя. 

В языке С++, в котором каждый объект имеет тип, результат работы операторов 
‚* или ->* является единственным исключением. Понять его еще сложнее, чем не- 
однозначность указателей на функции, вызванную перегрузкой, рассмотренную в 
предыдущем разделе. Там мы имели слишком много типов, но не могли сделать одно- 
значный выбор; здесь у нас вообще нет ни одного типа. По этой причине указатели 
на функции-члень и два связанных с ними оператора представляют собой удивитель- · 
но непродуманную концепцию в языке С++. Кстати, ссылок на функции-члены не 
бывает (хотя можно создать ссылки на обычные функции). 

В некоторых компиляторах языка С++ вводится новый тип, что позволяет хранить ре- 
зультат выполнения оператора .* с помошью следующей синтаксической конструкции. 


5 В описании стандарта языка С++ сказано: “Если результатом выполнения операторов . * 


и -> является функция, этот результат может быть использован лишь в качестве операнда опе- 
ратора вызова функции ()”. 
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// _сЛоѕиге — расширение языка, 

// определенное в некоторых компиляторах 

уосїд (-сТозиге:: *дегопітоѕмогк) О = 

дегопімо. *рдсїііу1іту; 

// вызываем нужную функцию 

дегопімоѕмогк() ; 

Тип значения, возврашаемого функцией дегопітомогК, не содержит никакой ин- 
формации о классе Раггот. Это значит, что в дальнейшем функцию дегопітомогк 
можно связать с другим классом. Все, что для этого нужно — тип возвращаемого зна- 
чения и аргументы указателя на функцию-член. Фактически это расширение языка 
представляет собой некую разновидность класса Рипстог, но его применение ограни- 
чено объектами и функциями-членами (на обычные функции и функторы это расши- 
рение не распространяется). 

Перейдем к реализации связывания указателей с функциями-членами класса 
Рипстог. Опыт работы с функторами и функциями подсказывает, что было бы хоро- 
шо остаться на высоком уровне абстракции и до поры до времени пренебречь специ- 
фикой. В реализации класса Мемғипнапд1ег тип объекта (в предыдушем примере им 
был класс Раггот) является шаблонным параметром. Более того, указатель на функ- 
цию-член мы также сделаем шаблонным параметром. Это позволит свободно выпол- 
нять автоматическое преобразование типов в реализации класса ЕипстогнапаТег, ко- 
торая приводится ниже. В этой реализации воплощены описанные выше идеи, а так- 
же некоторые идеи, уже использованные при разработке класса ғипстог. 

тетр1ате «сТа55 Рагептрипстог, турепате РоіптегтооБЬј) 

Турепате Ро1птегтометЕп> 
сТа55 метнапа1ег 
риб1'їс ғипстогІтр1 
< Е 
турепате Рагепїғипстог: : Кези1ттуре, 


хурепате Рағгепїғипстог: : Рагті 151 
> 


{ 
риБ11їс: 
Туреде+ турепаме РагепсЕйпстог::Кезиістуре кези]1ттуре; 
мемғипнапа1ег (сопѕт Роїптегтоббів, РоїпсегтометЕп рметгип) 
роьі (роьі), рметЕп_(СрметЕп) {} 


МетЕйпнапаТегх СТопе(О соп5і 
{ геигп пем мемрупнап ]ег(*тН1$); ) 


Вези1ттуре орегатог()() 


гетигп (С*роь)_).*рметЕи_) (); 


Вези1ттуре орегатог О (турепате Рагептрипстог: : Рагм1 р1) 
гехигп ((С*роь)_).*рметЕп_) Ср1); 

кези1ттуре орегатог()(турепате Рагептғипстог: : Рагт1 рі, 
Турепате РагепсЕипстог::Рагт? р2) 


гетиги СС®роьј_>. *рмепЕп._) (рі, р2); 
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рглуаее: 
РОо1птегтоо6] роб]; 
РОо1птегтометп рмемЕп_; 
}; 
Почему параметром шаблонного класса Метғипнапд1ег является тип указателя 
(роіптегтооБЬ]ј), а не тип самого объекта? Более естественно выглядела бы такая 
реализация. 


тетр1ате <с1аѕ5 Рагептғипссог, турепамте Обі) 
турепате РоіптегТометЕп» 
сТа55 метнапд1ег 
риб'їс ЕипстогІтр1 


< 
турепате Рагептғипстог: : Веѕи1ттуре, 
Турепате Рагептғипстог: : Рагтііѕт 
> 
{ . 
ргімате: 
обі" робі ; 
РоїпсегтометЕп рметмЕп_; 
риб1їс: 


метғипнапа1ег(оБј* роб], РоіпсегтометЕп рметғип) 

: роьј_Сроьј), рметЕп.(рМетЕп) {} 
Понять такой код было бы проще. Однако первая реализация является более обоб- 
шенной. Во вторую реализацию встроен тип “указатель на объект”, причем этот ука- 
затель представляет собой просто адрес объекта класса 05] и больше ничего. Может 
ли это создать проблемы? 

Конечно, если понадобится применить интеллектуальные указатели на объекты 
класса метрипнап ег. Убедились? Первая реализация поддерживает интеллектуаль- 
ные указатели, а вторая — нет. Первая реализация может хранить любой тип, дейст- 
вующий как указатель на объект, а вторая хранит и использует только простые указа- 
тели. Более того, вторая версия не работает с указателями на константы. Вот как про- 
- являются негативные черты жестко встроенных типов. 

Попробуем протестировать только что созданную реализацию на примере 
класса раггої. 

#1пс1иде "РЕипстог.Н" 


#іпс1иде <1о5тгеат> 
и5іпд патеѕрасе 514; 


с1аѕ5 Раггот 


рчЬ1їс: 
\014 ЕатО 
{ 


соит << "ням, ням, ням... Хп"; 
} 
уоїа Ѕреак() 
{ 


сои << "Пиастры! Пиастры! \п"; 


|: 
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іпо маіп() 


Раггої дегопіто; 
// Определяем два функтора 
ЕЧИССОГго» 
ста1(&дегопіто, &Раггот: ;еат), 
ста2 (&дегопіто, &рРаггот: : бреаК); 
// вызываем каждый из них 
сті1 0; 
ста2 О; 
} 
Поскольку класс МетрипНнап Тег должен быть как можно более общим, автомати- 
ческое преобразование типов выполняется совершенно свободно — абсолютно так же, 
как и в классе Еипссогнапд]ег. 


5.10. Связывание 


На этом мы могли бы остановиться. Теперь у нас все есть — класс Еийсбог под- 
держивает все вызываемые сущности языка С++, определенные выше, причем делает 
это весьма успешно. Однако, как мог убедиться Пигмалион, начиная работу; невоз- 
можно предсказать, каков будет еє результат. 

Поскольку класс Еипсбог уже готов, возникают новые идеи. Например, хотелось бы 
иметь возможность конвертировать тип Рипстог в другой тип. Одним из таких преобразо- 
ваний является связывание (Біпаіпе). Пусть задан класс рипсфог, получающий целые числа. 
Мы хотим связать одно из этих целых чисел с некоторым фиксированным значением, а 
второе оставить переменным. Такое связывание порождает новый класс Бипсбог, полу- 
чающий только одно целое число, поскольку второе зафиксировано и, следовательно, из- 
вестно. Описанное выше связывание иллюстрируется следующим примером. 


мої РО 
{ 


// Определяем функтор с двумя аргументами 
Ғипссог<уоій, ТҮРЕШІЅТ_2 (1пі, іп) > ста1(ѕотесћіпд); 
// связываем первый аргумент со значением 10 
Ейпсгогхмоїд, іпт> сма2 (Ввіпағігѕт(ста1, 10)); 
// эквивалентно ста1(10, 20) 
ста2 (20); 
// Затем связываем первый (и только первый) аргумент 
// функтора ста2 со значением 30 
Ейиссогхуоїд» стаз Свіпағігѕ є (ста2, 307); 
// Эквивалентно · ста1 (10, 30) 

і стаз 0; 


Связывание — мощное оружие. Оно позволяет хранить не только вызываемые 
сущности, но и часть (или все) их аргументы. Это значительно расширяет возможно- 
сти функторов, поскольку теперь можно упаковывать функции и аргументы, не при- 
бегая к генерации дополнительного кода для их связывания. 

Например, представьте себе реализацию операции повтора (тедо) в текстовом ре- 
дакторе. Когда пользователь набирает букву “а”, выполняется функция 0оси- 
тепт: :Іп5егсСпаг('а"). Добавим готовый функтор, содержащий указатель на класс 
Роситепт, функцию-член Іп5егтСпаг и фактический символ. Если пользователь вы- 
полняет в меню пункт Кедо, достаточно лишь активизировать функтор — и все. Более 
подробно операции отката и повтора обсуждаются в разделе 5.14. 
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Связывание является мощным средством еще и по другой причине. Представьте, 
что вы применяете класс Ғипстог для вычислений, а его аргументы — это окружение, 
необходимое для их выполнения. До сих пор класс Ғипсїог задерживал вычисления, 
сохраняя указатели на функции. и указатели на методы. Однако в классе Ғипстог хра- 
нятся лишь вычисления, но нет информации об их окружении. Связывание позволяет 
функтору хранить часть окружения вместе с вычислениями и сократить потребность в 
пересылке переменных окружения во время вызова. 

Перед тем как перейти к реализации, подытожим наши требования. В конкретиза- 
ции класса Ғипстог<А, Ті151> мы хотим связать первый аргумент (ті151: :Неаа) с 
фиксированным значением. Следовательно, типом возвращаемого значения является 
класс Ейпсбог«В, Ті151::Таї1>. 

Реализовать класс ВіпаегЕї г5Т очень легко. Нужно лишь учесть, что здесь исполь- 
зуются две конкретизации класса Рипстог: входная и результирующая. Входной тип 
Ейпстог передается в качестве параметра Рагепегипстог, а результирующий тип 
Ғипстог вычисляется. 

тетр1ате <с1аѕѕ Іпсотіпд» 

сТа55 ВіпаегЕігѕт 


рибТіс ҒипсёогІтр1<т®урепате Іпсотіпд: : Вези1 туре, 
турепате Іпсотіпд::Агдитепс5::Таї 1» 


хуредеї гипстог<турепате Іпсотіпда: : кеѕи1ттуре, 
Тпсом1 пд: :Агдитепї5: :Та11> Оитадоіпд; 
хуредеї сурепате Іпсотіпд::Рагті Воипа; 
хуредеї турепаме Іпсоті пд: : Кеѕи1+Туре КезиТстуре; 
риБТ1їс: 


віпдӢегЕігѕ1(сопѕт Іпсотіпдв Рип, воцпа Боип@) 
Типо(ЖТип), Ббойпа (бБоипа) 


{ 

} 

Віпаегеїгѕ1* СТопе(О сопѕт 

| гетигп пем ВіпдегЕіг5С("СНі5); } 


Кези1‹туре орегасогГ 0 О 
{ 


гетигп Ғип._СБоипа_); 


} 
Кеѕи1тТтуре орегасог ОО Стурепате Оитдоіпд: : Рагт1 р1) 


гетип Ёип__СбБоипа_, р1); 
} 


Кези]‹туре орегатог()(хурепате Оитдоіпд: :Рагт1 рі, 
хурепате Сисдоїпд::Рагт2 р2) 


гехигп Ғип__СБоипа_, рі, р2); 


) 
ргімате: 
Іпсотіпд Фип_; 
воипа Боипад,;; 
}; 
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Шаблонный класс віпаегЕігѕт работает в сочетании с шаблонной функцией 
Ввіпағігѕт. Достоинством шаблонной функции Віпағігѕтє является то, что она авто- 
матически выводит свои шаблонные параметры из типов получаемых ею фактических 
параметров. 


// Определение класса ВіпаегЕї г5{Тга1т$ 
. // находится в файле Ғипстог.һћ 
тетр1ате <с1а55 ЕсТог> 
хурепате Ргіуате: : ВіпдегЕі гѕ1тгаіїѕ<Есіог> : : ВоипағипстогтТуре 
віпағігѕ1( 
сопѕ1 Рсог& Ғип, 
Турепате Естог: : Рагт1 Боипа) 


1 
туреде{ турепате 
ргіуате: : в1паегЕ1 гзттга1 т$<Естог> : : Воипағипстогтуре 
бисдоїпод; 
гетигп Оитдоіпа (5711: : аито_ріг<турепате битдоїпд: : ттр1> ( 
пем ВіпаегЕігѕе<Естог> (Рип, Боипа))); 
} і 


Связывание прекрасно сочетается с автоматическим преобразованием типов, наде- 
ляя класс Ғипстог невероятной гибкостью. Это иллюстрирует следующий пример. 


соп5Е сһаг* Ейп(їпс 1, іп? і) 


соиї << Ғип(" << і <<", << і << ") саТеа\п"; 


іп паї О 


Ейпстог«соп5ї сһаг*, ТҮРЕШІЅТ_2 (сһаг, іп)» Ғ1СЕип); 
Ейпстог«5сд::5сгіпд, ТУРЕЦІ5Т 1(доцібЛе)» #2 

" ВіпдЕїг5ЄСФ1, 10)); 

// выводит на печать строку “Рип(10, 15) са11еа” 

2 (15); 


5.11. Сцепление 


В книге Сатита её а[. (1995) приведен пример класса масгоСоттапа, в котором 
хранится линейный набор (список или вектор) объектов класса Соттапа. При выпол- 
нении этого класса последовательно выполняются все хранящиеся в нем команды. 

Это свойство может оказаться очень: полезным. Например, вернемся к примеру, свя- 
занному с откатом и повторным выполнением операции ипдо/тедо. Каждая операция "до" 
должна сопровождаться несколькими операциями отката “ипдо”. Например, вставка сим- 
вола может автоматически приводить к прокрутке текстового окна (в некоторых текстовых 
редакторах эта операция применяется для улучшения внешнего вида текста). Отменяя эту 
операцию, вы возвращаете окно в прежнее положение. (В большинстве текстовых редак- 
торов эта операция реализована неправильно. Досадно!) Чтобы выполнить обратную про- 
крутку (ипестоїї), нужно хранить несколько объектов класса Соттапа в одном объекте клас- 
са Ғипстог и выполнять их как одно целое. Функция-член боситепт: :Іп5ег'Спаг затал- 
киваєт обьект класса МасгоСоттапа в стек отката. В состав класса МасгоСоттапа могут 
входить функции-члень роситепі: :беТетесСнаг и м'іпаом: :5сго11. Последнюю функцию 
можно связать с аргументом, запоминаюшим старое состояние. (И вновь связывание ока- 
зывается очень удобным инструментом.) 
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В библиотеке Го определен класс ЕипстогСНаї п и вспомогательная функция СНаї п. 


хетрТаге <с1аѕ5 Ғип1, с1аѕѕ Ғип2> 
Рип? Сһаїп( 
сопѕє Еип1& Ғип1, 
сопѕї Еип2& Ғип2); 
Реализация класса Ғипсеогсһаіп тривиальна — он хранит два функтора, а оператор 
ҒипстогСһаіп: : орегатог() вызывает их один за другим. 

Функция Сһаіп завершает наше описание поддержки макрокоманд. Одно из дос- 
тоинств такой реализации заключается в том, что список команд неограничен. Ни 
шаблонная функция Віпағігѕї, ни функция Сһаіп не требуют вносить никаких из- 
менений в класс Ғипстог. Это свидетельствует о том, что вы сами можете разработать 
аналогичные функциональные возможности. 


5.12. Первая практическая проблема: стоимость 
функций пересылки 


В принципе разработка шаблонного класса Ғипсїог завершена. Теперь мы сосре- 
доточимся на вопросах его оптимизации, стремясь, чтобы он работал как можно эф- 
фективнее 5 

Рассмотрим в классе Ейпстог одну из перегрузок оператора (), пересылающую 
вызов интеллектуальному указателю. | 


// внутри класса Ейпсбог«в, Ті150» 
к орегатог() (Рагті рі, Рагт2 р2) 


гетип (*5рттр!_)(р1, р2); 
} - 
При каждом вызове оператора () создается ненужная копия каждого аргумента. Если 
классы Рагті и Рагт2 достаточно велики, это снизит производительность работы 
программы. 

Довольно странно, но даже если оператор () класса Ғипстог сделать подставляе- 
мым (шНпе), компилятор будет по-прежнему тиражировать лишние копии аргумен-. 
тов. В задаче 46 книги Саттера (бийег, 2000) описывается современная модификация ' 
языка, сделанная непосредственно перед его стандартизацией. Функциям пересылки 
было запрещено создавать копии (ей тд Гог сору сопѕігисіїоп). Компилятору позволено 
создавать копии лишь для возвращаемого значения, поскольку возврат значений нель- 
зя оптимизировать вручную. 

Помогут ли ссылки решить эту проблему? Используем следующий код. 


// внутри класса Еийпсбог«В, ТіїѕТ> 
к орегасогО (Рагт1& рі, Рагт2& р2) 
1 


гетигп С*=рітр1_) (р1, р2); 


6 Обычно преждевременная оптимизация нежелательна. Одна из причин заключается в том, 
что программисты не могут правильно определить, какую часть программы следует оптимизи- 
ровать, а какую — нет (что еще важнее). Однако разработчики библиотек находятся в другой 
ситуации. Они не знают, будут или нет использованы их библиотеки в критически важных час- 
тях какого-то приложения, поэтому стремятся максимально оптимизировать библиотеку. 


144 Часть Н. Компоненты 


Все это выглядит прекрасно и может на самом деле работать, пока вы не попробуете 
выполнить такой код. 
моїд теѕтғипстіоп(ѕта: :51г1іпо&, іп); 


Еипстог<моій, ТУРЕЕТЗТ_2 (514: :51гіпа&, іп)» 
ста (тезерипс Топ); 


5єгіпд 5; 

ста(5, 5); // Ошибка! 

Компилятор споткнется на последней строке, выдав сообщение: “Ссылки на ссыл- 
ки не допускаются!”. (На самом деле сообщение может быть более таинственным.) 
Фактически такая конкретизация может преобразовать класс Рагт1 в ссылку на объ- 
ект класса 504: :51г1пд. Следовательно, объект рі может стать ссылкой на ссылку на 
объект класса 514: : $Ег1пд, а это не допускается. 

К счастью, решение этой проблемы существует. В главе 2 описан шаблонный 
класс ТуреТгаї є5«Т», определяющий группу типов, связанных с типом Т. К ним от- 
носятся неконстантные типы (если тип Т является константным), указатели (если тип 
Т является указателем) и многие другие. Тип, который можно безопасно и эффектив- 
но передавать как параметр функции, называется Рагатетегтуре. В приведенной ни- 
же таблице показана связь между типом, передаваемым классу туретгаітѕ, и внут- 
ренним определением типа Рагатетегтуре. 


т Туретгаітѕ<т> : :Рагаметегтуре 

9 Тип у, если у — элементарный тип; в противном случае — соп5С О & 
соп5т у Тип у, если у — элементарный тип; в противном случае — сопзЕ Ц & 
у & у & 


сопѕі о & соп5с Ц & 


Замена аргументов функции пересылки типами, указанными в правом столбце, 
всегда корректна, причем она не вызывает никаких дополнительных затрат, связан- 
ных с копированием. 

// Внутри класса Рипстог<в, тііѕт> 

А орегасог 0 ( 


Турепате ТуреТгаї є5«Рагт1»: : Рагатетегтуре р1; 
сурепате Туретга1 с5«Рагт2»: : Рагапетегтуре р2; 


РА 
гесигп (*5рттр1_)(р1, р2); 
Еще приятнее то, что эти ссылки прекрасно работают в сочетании с подставляе- 
мыми функциями. Оптимизатор легче генерирует оптимальный код, поскольку для 
этого ему достаточно установить ссылки. 


7 Эта проблема также возникает при работе со стандартными механизмами связывания. 
Бьярн Страуструп представил Комитету по Стандартизации отчет об этом дефекте. Он предло- 
жил исправить этот недостаток, разрешив ссылаться на ссылки и обрабатывать результирующие 
ссылки как простые. В момент написания книги этот отчет был доступен на У/еб-странице 
Неер: : //апибіѕ .акиид.ак/јес1/5с22 /м921/40с5/смд_астіме. һт1#106. 
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5.13. Вторая практическая проблема: распределение 
динамической памяти 


Оценим затраты, связанные с созданием и копированием функторов. Мы должны реа- 
лизовать правильную семантику значений, но это связано с проблемой распределения ди- 
намической памяти. Каждый объект класса Еипстог содержит интеллектуальный указатель 
на объект, созданный с помощью оператора пем. Для создания копии объекта класса 
Ғипстог функция-член рипстогттр] : :СТопе выполняет глубокое копирование. 

Это особенно неприятно, если размер объектов очень важен. В большинстве случаев 
класс Ғипстог используется с указателями на функции и парами, состоящими из указате- 

"лей на объекты и указателей на функции-члены. В типичных 32-разрядных системах эти 

объекты занимают от 4 до 20 байт соответственно (4 байт для указателя на объект и 16 
байт для указателя на функцию-член*). При использовании связывания размер конкрет-! 
ного функтора увеличивается примерно на величину связываемого аргумента (вследствие 
выравнивания блоков памяти его размер может еще ненамного вырасти). 

В главе 4 описаны эффективные механизмы распределения памяти для небольших 
объектов. Класс РипстогТмр] и его наследники являются превосходными кандидата- 
ми на применение этих механизмов распределения памяти. Напомним, что один из 
способов применения механизма распределения памяти для небольших объектов за- 
ключается в создании класса, производного от шаблонного класса $та11063ест. 

Использовать этот класс очень легко. Однако нам нужно добавить в класс Ғипсїог 
шаблонный параметр, отображающий потоковую модель в механизме распределения па- 
мяти. Это не сложно, поскольку большую часть времени используется аргумент, заданный 
по умолчанию. В приведенном ниже коде изменения выделены полужирным шрифтом. 


тетр1ате 

< 
с1аѕ5 к, 
с1аѕ5 ТІ, 


тепр1асе <с1а55 т> 
сТа55 Тигеадіпдмоде? = ОБЕРАЧЕТ_ТНВЕАОТМС 
> 


с1аѕ5 гипстогттр] : риБ1іс ѕма1106јесі<Тһгеааіпдмоае1> 
рибіїс:. 


как и раньше 
У; 


Все это наделяет класс гипстогтир1 функциональными возможностями механизма 
распределения памяти. 
Аналогично в сам класс Еипстог добавляется третий шаблонный параметр. 


тетр1ате 

< 
СТаз$$ В, 
с1аѕѕ ТІ, 


сетр1ате <с1аѕ5 т> В 
с1аѕ5 тһгеадіпдмойе1 = БЕРАЦЕТ_ТНВЕАРТМС 


8 Естественно было бы ожидать, что указатель на функцию-член занимает 4 байт, как и ука- 
затель на обычную функцию. Однако указатели на методы фактически представляют собой раз- 
меченные объединения (гаввед иптоп). Они применяют множественное виртуальное наследова- 
ние и виртуальные/невиртуальные функции. 
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> 


с1аѕѕ ЕипсбоОГ 


гіуате: 

4 // Передаем параметр Тргеад1пдМмо4е] классу Еипстогттр1 

$Е4: :аибо_рег<Рипстогттр1<А, Ті, Тигеадіпдумодеї» рттр1_; 

у; 

Для того чтобы использовать класс Ейпстог со стандартной потоковой моделью, 
третий шаблонный аргумент не нужен. Только если в приложении понадобятся функ- 
‘торы, поддерживающие несколько потоковых моделей, нужно явно указать параметр 
тһгеааїпдмоае1. 


5.14. Реализация операций ЦИпдо и Ведо с помощью 
класса Еипсїог 


В книге Сатта еї а! (1995) рекомендуется реализовывать операцию ип4о с помо- 
щью дополнительной функции-члена упехесите класса Соттапа. Проблема заключа- 
ется в том, что эту функцию невозможно выразить в обобщенном виде, поскольку от- 
ношение между некоей операцией и ее отменой. (ип4о) нельзя предсказать. Решить 
зту задачу можно, если созлать отдельный класс Соттапа для каждой операции, вы- 
полняемой в приложении. Однако подход, основанный на применении класса Рипс- 
сог, ориентирован на использование одного класса, связываемого с разными объек- 
тами и вызовами функций-членов. 

Статья Ала Стивенса (АІ Ѕісуепѕ) в журнале Пг. Дофіз Лоита! (Злеуепз, 1998) может 
оказать нам огромную помощь в изучении обобщенных реализаций операций ип4о и 
гедо. Стивенс создал обобщенную библиотеку операций ичпдо/те4о, которую следует 
тщательно изучить, независимо от того, будете вы применять класс ғипсїог или нет. 

Это все, что нам следует знать о структурах данных. Основная идея операций ипдо и 
ге4о заключается в использовании стека отката (ипдо ѕЅіаск) и стека повтора операций 
(гедо $асК). Если пользователь выполнил некое действие, например, набрал букву на 
клавиатуре, в стек отката заталкивается новый функтор. Это означает, что функция-член 
роситепі: :Іпѕегтсһаг должна затолкнуть в стек отката действие, обратное по отноше- 
нию к операции вставки символа (например, функцию-член росимепт: : ре1етесћаг). 
Основная нагрузка переносится на функцию-член, которая действительно выполняет 
операцию отката, а в классе Рипстог информация о том, как именно следует выполнять 
эту операцию, не хранится. 

При необходимости можно затолкнуть в стек повторения операции функтор, со- 
стоящий из класса Ооситепі и указателя на функцию боситеп*: :Іп5егіСНаг, свя- 
занных с фактическим символьным типом. Некоторые текстовые редакторы позволя- 
ют “повторный набор” (гетуріпе). После того как вы что-то набрали на клавиатуре и 
выбрали в меню пункт Ведо, повторяется блок введенных символов. Для этого пре- 
красно подходит связывание, реализованное в классе Рипс®ог, позволяющее хранить 
вызов функции-члена боситепт: :Іпѕегїісһағ для заданного символа, инкапсулируя 
такие вызовы в одном функторе. Кроме того, повторить нужно не только символ, на- 
бранный последним (это было бы не слишком впечатляющим достижением), но и 
всю последовательность символов, набранных после выполнения последней опера- 
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ции, не связанной с набором. Здесь в действие вступает сцепление, реализованное в 
классе рипс®ог. По мере того как пользователь вводит все новые и новые символы, 
создаются все новые и новые функторы. Таким образом, возникает возможность вы- 
полнить последовательность нажатий клавиш как одну операцию. 

Функция-член оосимтепт: :Іпѕегїсһаг, по существу, заталкивает функтор в стек 
отката. Когда пользователь выбирает пункт меню Џпао, этот функтор должен быть 
выполнен и затолкнут в стек повтора операций. 

Как видим, связывание аргументов и сцепление позволяют нам м работать с функторами 
единообразно: вид вызова не имеет значения, поскольку он скрыт внутри функтора. Это 
значительно облегчает задачу реализации операций отката и повтора операций. 


5.15. Резюме 


Использовать хорошие библиотеки на языке С++ намного легче, чем создавать. С 
другой стороны, разрабатывать библиотеки очень интересно. Оглядываясь на детали 
описанных выше реализаций, можно извлечь несколько уроков, касающихся создания 
обобщенных программ. 


» Создавайте гибкие шаблонные типы. Стремитесь на все смотреть с максимально 
общей точки зрения. Классы Кипсбогнапаїег и Меткипнапаїег приобрели много 
преимушеств, благодаря тому, что в них используются шаблоны. Указатели на 
функции предоставляют большую свободу. По сравнению с их функциональными 
возможностями получающийся код имеет удивительно небольшой размер. Все эти 
выгоды достигаются благодаря использованию шаблонов и тому, что компилятору 
предоставлено право самому выводить типы, когда это возможно. 


• Обобщенное программирование способствует созданию семантики первого 
класса (см. примечание в начале главы. — Прим. ред.). Было бы крайне затруд- 
нительно оперировать исключительно указателями на класс ҒипсіогІтр1. 
Представьте себе, как в этих условиях реализуются связывание и сцепление. 


Изошренные технологии предназначены для достижения большей простоты. На 
основе всех этих шаблонов, наследования, связывания и управления памятью создана 
простая, легкая в применении и хорошо продуманная библиотека. 

В двух словах, класс Ғипсїог задерживает вызов функции, функтора или функции- 
члена. Он сохраняет вызываемый объект и предоставляет для его вызова оператор ©). 
Ниже приведено краткое описание этого класса. 


5.16. Краткое описание класса Рипсфог 


Класс Рипсбог является шаблонным и позволяет выражать вызовы функций, 
имеющих до 15 аргументов. Первым шаблонным параметром является тип возвра- 
щаемого значения, вторым — список типов, содержащий типы параметров функции. 
Третий шаблонный параметр задает потоковую модель, которая используется меха- 
низмом распределения памяти, применяемым в классе гипстог. Подробная инфор- 
мация о списках классов приведена в главе 3, о потоковой модели — в приложении, о 
механизме распределения памяти для небольших объектов — в главе 4. 


• Объект класса Ғипс+ог можно инициализировать функцией, функтором, дру- 
гим объектом класса Рипсфог или указателем на объект и указателем на метод, 
как показано в приведенном ниже примере. 
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моіа ғипстіоп(іпт) 
ѕТгисТ ЅотеЕипстог 


усій орегатог() (їп+) ; 


8тгисі ЅотеС1аѕ5 


усій метБегРипсетоп (тит); 


}; 
уо1іа .ехатр1е() 


// инициализируем класс Еипстог функцией 
ҒипсТог<моій, ТУРЕЦІ5Т 1(іпс)» ста1 СЕипстіоп) ; 
// Инициализируем класс Рипстог функтором 
ЅотеЕипстог Ёп; 
ЕиПСТОР<У01й, ТҮРЕЦІЅТ_1(1пї)> ста2 СҒп) ; 
// Инициализируем класс Ғипстог указателем на объект 
// и указателем на функцию-член 
ѕотеС1аѕ5 тубрбіесі; 
Ейпсбог«муоїй, ТҮРЕШІЅТ._1(1пїі)> стаз С&туобјест, 
&отес1а$$ : :Метбегрипстіоп) ; 

// Инициализируем класс ғипстог другим объектом 
// класса Еипстог (копирование) 

7 Ейпсбог«уУоїйд, ТҮРЕЕІЅТ_1(іпїт)> ста4 (стаз); 


• Объект класса Ейпсбог можно инициализировать обьектом класса 


5сд::айсо-рісг« Еипсбогітрі«В, ТЕ1$*%> >. Это позволяет создавать расшире- 
ния, определенные пользователем. 


• Класс Ғипстог поддерживает автоматические преобразования типов аргументов 
и возвращаемых значений. Например, в предыдущем примере функции-члены 
$отерипстог: :орегатог() и 5отеСТа55::МетбегЕйпссіоп могут получать ар- 
гументы типа доу Те вместо аргументов типа іпг. 


® При перегрузке функций-членов следует создавать дополнительный код для 
устранения неоднозначности. 


• Класс ғипстог полностью поддерживает семантику первого класса: копирова- 
ние, присваивание и передачу по значению. Класс Ецпсбог не является ни по- 
лиморфным, ни базовым. Если нужно расширить класс Ғипстог, в качестве ба- 
зового следует применять класс Еипстогттр1 


• Класс гипстог поддерживает связывание аргументов. Вызов шаблонной функ- 
ции Віпдєіг5т связывает первый аргумент с фиксированным значением. В ре- 
зультате возникает параметризованньй класс Еипсфог, параметрами которого 
являются остальные аргументы. Рассмотрим пример. 


уста #0) 
{ 


// Определяем класс Еипстог с тремя аргументами. 

випссог«моїд, ТУРЕЦІЗ5Т. З(їпс, їпс, доцте)» стаї( 
ѕотеЕпїї су); 

// Связьваєм первьй аргумент с числом 10 

Ғипсіог<моіа, ТУРЕЕТ$Т_2(1пе, фоцбЛе)» ста? ( 
Ввіпдвіг5с(стаї, 10); 
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// эквивалентно вызову ста1(10, 20, 5.6) 
см2 (20, 5.6) 


е Используя функцию Сһаіп, в одном объекте класса ғипстог можно сцепить не- 
сколько объектов этого класса. 


\014 ҒО 
{ 


ғипссог<> стаі (ѕотесћіпд) ; 

Ейпсбоге» ста2 (ѕЅотетћіпдЕ1ѕе); 

// Сцепливаем объекты сті) и стй2 в контейнер 

Еупсбог«» ста3 (Ссһаіп (стд1, ста2)); 

// эквивалентно ста1(); ста2 (0); 

стаз) ; 

} 
• Затраты, связанные с использованием простых объектов класса гипстог, состо- 

ят из одной переадресации (вызова через указатель). При каждом связывании 
или сцепливании возникает один дополнительный виртуальный вызов. Пара- 


метры копируются только при необходимости преобразования. типов. 


е Шаблонньй класс гипстогтир! использует механизм распределения памяти 
для небольших объектов, описанный в главе 4. 
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РЕАЛИЗАЦИЯ ШАБЛОНА 5ІМСЦЕТОМ 


Шаблон проектирования ѕіпдЛетоп (Сатта єї аі., 1995) представляет собой уникаль- 
ную комбинацию простого описания и сложной реализации. Об этом свидетельствуют 
многочисленные книги и журнальные публикации (например, УІіззідез, 1996, 1998). Опи- 
сание шаблона 5іпд1етоп в книге Сатта еї аі. (1995) весьма просто: “Шаблон гарантиру- 
ет, что класс имеет только один экземпляр и обеспечивает глобальный доступ к нему”. 

Синглтон — это улучшенный вариант глобальной переменной. Новшество заключа- 
ется в том, что второй объект типа 51па1етоп создать нельзя. Следовательно, синглтоны 
можно использовать в приложениях при моделировании типов, имеющих только один 
экземпляр, таких как кеубоага, ріѕр1ау, Ргіпїмападег и 5у5 гетСТосК. Создавать вто- 
рые экземпляры таких классов совершенно неестественно и, кроме того, опасно. 

Глобальный доступ имеет скрытые побочные последствия — с точки зрения кли- 
ента объект класса $1п91етоп владеет самим собой. Для создания объекта класса $1п- 
91етоп клиент ничего не должен делать. Следовательно, объект класса 5іп91 сопе сам 
создает и разрушает себя. Управление продолжительностью жизни синглтона пред- 
ставляет собой головоломную задачу. 

В этой главе обсуждаются наиболее важные вопросы, связанные с проектировани- 
ем и реализацией разных вариантов класса $1п9]1етоп в языке С++. 


« Свойства, которые отличают синглтон от обычной глобальной переменной. 
е Основные идиомы языка С++ для поддержки синглтонов. 

® Обеспечение уникальности синглтона. 

• Уничтожение синглтона и распознавание доступа после уничтожения. 


• Усоверщенствованноє управление продолжительностью жизни объекта класса 
5119 1 сопе. 


• Многопоточность. 


Мы опишем способы решения перечисленных выше проблем, а затем применим 
их для реализации обобщенного шаблонного класса 51по1етопнНо1йег. 

“Оптимальной” реализации шаблона проектирования $1па1етоп не сушествует. В 
зависимости от конкретной задачи наилучшими оказываются различные реализации, 
включая машинно-зависимые. Подход, описанный в этой главе, предназначен для 
разработки семейства реализаций на основе обобщенного скелета класса в духе проск- 
тирования на основе стратегий (глава 1). Класс 5іпдТетопНапа оставляет также воз- 
можности для его расширения и настройки. 

В конце этой главы мы разработаем шаблонный класс 5іпд1етопноїег, способ- 


ный генерировать много синглтонов разного типа. Класс 51 пд91есопно14ег предостав- 


ляет программисту возможности для детального управления распределением памяти 
при создании и уничтожении синглтонов при условии, что это не создает опасности 
для потоков. Кроме того, класс определяет, что делать, если пользователь попытался 
обратиться к уже разрушенному синглтону. Шаблонный класс 5$1па1екопно14ег пре- 
доставляет программисту функциональные возможности, выходящие за рамки обыч- 
ных типов, определенных пользователем. 


6.1. Статические данные + статические функции != 
синглтон 


На первый взгляд кажется, что для создания класса $1п91етоп нужны лишь стати- 
ческие функции-члены и переменные-члены. 


с1аѕ5 Роме { ... У; 
сТа55 РгіптегРогі (... У; 
сТа55 РгіпїјоЬ { ... } 


сТа55 МуОПТуРгіптег 


рибб'іс: 
зхасіс моїй дааргіптзоЬСргіптјоБ& пем2оЬ) 


іФ(ргіпсдиєце .епреу(0 && ргіпсіпдРогі .амаї Тар1е 0) 
1 
ргіпсіпдРогі , ѕепа(пемјоБ.рата()); 


е1ѕе 


{ 


ргіптдиеие_.. риѕћ (пем2о6); А 


} 
ргімате: 
// все данные являются статическими 
ѕтатіс $14: :диеце<Рг1ит206> ргіпєдивеиєе ; 
з5сасіс РгіпсегРогі ргіпсіпдРогі,; 
ѕтасіс коме даебайТевопі,,; 
} 


Ргіпс20рб зотеРгіпс20ь("Муроситепі схе") ; 

муоп1уРгіптег: :АдЯаРГіпс20ь(зотергіпс2об); 

Однако это решение! в некоторых ситуациях имеет много недостатков. Основная про- 
блема заключается в том, что статические функции не могут быть виртуальными, что не 
позволяет изменять поведение объекта при открытии кода класса Муоп1уРг1пеег. 

Кроме того, инициализация и удаление объекта затрудняются. В классе муоп- 
1уРгіптег нет конкретных точек, в которых инициализируются и удаляются данные, 
хотя эти задачи могут быть нетривиальными — например, переменная-член деҒаи1+- 
Ғопт_ может зависеть от скорости обмена данными порта, поведение которого описы- 
вается переменной рг1пЕ1поРог*_. 

Таким образом, реализация синглтонов сводится к созданию и управлению уни- 
кальным объектом, при этом создавать другие объекты такого типа запрещено. 


1 На самом деле этот код иллюстрирует шаблон проектирования МопоѕТаїе (Ваї! ала 
Стамѓогӣ, 1998). 
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6.2. Основные идиомы языка С++ для поддержки 
.синглтонов 


Чаше всего синглтоны создаются с помощью вариаций следующей идиомы. 


// Заголовочньй файл $1п91етоп.И 
с1аѕѕ 5іпдТесоп 


риБ1їс: 
5сасіс $1п91етоп* Іп5сапсе (0 // Единственная точка доступа 
1 
1Р (!ртпзтапсе_) 
рІпѕТапсе_ = пем 5іпдТетоп; 
гесигп ртп5тапсе_; 


операции 
ре1уате: 
5іпдТесоп(О; // предотвращает создание нового 
// объекта класса $1пд]ефоп 
$1п91етоп(соп5т 51и91етоп&); // предотвращает создание 
// копии объекта класса $1п91ефоп 
5згасіс 51пд1етопё&* рІпѕТапсе_; // Единственный экземпляр 


// Файл реализации 5іпдТесоп.срр 

Ѕіпд1етоп* $1п91етоп: :рІпѕтапсе_ = 0; 

Поскольку все конструкторы закрыты, код пользователя не может создать объект 
класса $1п91етоп. Однако класс содержит функции-члены, в частности, функцию Іп- 
5 сапсе, которые позволяют создавать объекты. Следовательно, требование уникально- 
сти объекта класса 51пд1етоп накладывается на этапе компиляции. В этом и заклю- 
чается суть реализации шаблона проектирования $1па1етоп в языке С++. 

Если объект класса $1п9]ефоп никогда не используется (в программе нет вызовов 
функции Іпѕтапсе), он не создается. Для осуществления такой оптимизации в начале 
функции Тптапсе выполняется дополнительная проверка (обычно весьма несложная). 
Преимущество такого подхода становится значительным, если объект класса 51іпо1еїоп 
требует для своего создания больших затрат и в то же время редко используется. 

Есть большое искушение упростить класс, заменив указатель рІп» гапсе.. в преды- 
дущем примере полноценным объектом клаєса 51пд1етоп. 


//Заголовочный файл $1пд1етоп.И 
сТа55 5іпдТесоп 


руБЛ1с: 
5схасіс $1п9]етоп* Тизфапсе() // Единственная точка доступа 


{ 


ү 
іп Ооѕотесћіп9(); 
ргімате: ; 
5сасіс 5іпдієгоп іпѕтапсе_; 


гетиги &1пзтапсе_; 


// Файл реализации 5іпдТесоп.срр 
5іпдТесоп 51пдТ1етоп: : 1п5тапсе_; 


Это неудачное решение. Несмотря на то что переменная 1п5тапсе.. является ста- 
тическим членом класса 5іпд1егсоп (как и указатель рІпѕтапсе_ в предыдущем при- 
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мере), между этими вариантами есть существенная разница. Переменная-член іп- 
5 апсе. инициализируется динамически (с помощью вызова конструктора класса $1п- 
дТесоп во время выполнения программы), в то время как переменная ртпзтапсе_ 
инициализируется статически (она относится к злу; не имеющему конструктора, и 
инициализируется статической константой). 

Компилятор выполняет статическую инициализацию до первого оператора компо- 
новки (аззету орегаїог) программы. (Обычно статическая инициализация соответст- 
вует файлу, содержащему выполняемую программу, т.е. загрузка — это инициализа- 
ция.) С другой стороны, в языке С++ не определен порядок динамической инициали- 
зации объектов, принадлежащих разным транслируемым модулям (ітапзіаціоп мпИ$), 
что приводит к многочисленным недоразумениям. (Прще говоря, транслируемый мо- 
дуль — это компилируемый исходный файл.) Рнесмотрим следующий код. 

// зотер1 Те. срр 

#іпс1ибе "5іпдТетоп.һ" 

іп д1оБа1 = 51іпдТетоп: : Іпѕтапсе() ->роѕотеїћіпд() ; 

В зависимости от порядка инициализации, выбранного компилятором для пере- 
менных іпѕтапсе_ и д1ођБа1, вызов функции-члена 51п91етоп; :Іп5 апсе может воз- 
вращать объект, который еще не создан. Это значит, что переменную 1пзтапсе_ 
нельзя считать проинициализированной, если ее использует другой внешний объект. 


6.3. Обеспечение уникальности синглтонов 


Обеспечить уникальность объекта класса $1паТетоп можно несколькими способа- 
ми. Некоторые из них мы уже применяли. Это закрытые конструктор по умолчанию и 
конструктор копирования. Их применение блокирует код, приведенный ниже. 

51па1етоп зпеаКу(*$1па1Тетоп: :Іп5тапсе 0); // Ошибка! 

// Не позволяет создать копию 5пеаКу объекта класса 5іпд1етоп, 

// возвращаемого функцией-членом Тпзтапсе 
Если не определить конструктор копирования, компилятор сам создаст открытый 
конструктор (Меуегѕ, 1998а). Объявление явного конструктора копирования блокирует 
автоматическую генерацию, и размещение конструктора в разделе ргімате вызовет 
ошибку на этапе компиляции. 

Ситуацию можно немного исправить, если позволить функции-члену Тпзтапсе 
возвращать ссылку, а не указатель. Проблема, связанная с указателем, возврашаемым 
функцией-членом Іпѕїапсе, заключается в том, что вызывающий код может попы- 
таться удалить его с помощью оператора ае1ете. Для того чтобы минимизировать ве- 
роятность этого события, безопаснее возвращать ссылку. 

// внутри класса 5іпдТетоп 

зхасіс $1п91етоп& іпзсапсе О; 

Другая функция-член, генерируемая компилятором по умолчанию, представляет 
собой оператор присваивания. Уникальность объекта не связана с оператором при- 
сваивания непосредственно, однако одно из ее очевидных последствий заключается в 
том, что присваивать один объект другому нельзя, поскольку два объекта класса 5іп- 
91етоп одновременно существовать не могут. Для объекта класса 51п91етоп любое 
присваивание оказывается самоприсваиванием (ѕе!Ғ-аѕѕірмтепќ), не имеющим ника- 
кого смысла. Следовательно, следует заблокировать оператор присваивания (сделав 
его закрытым и никогда не реализуя). 
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Последний уровень защиты создается закрытым. деструктором. Эта мера предот- 
вращает случайное удаление указателя на объект класса 51іпд1етоп. 
Таким образом, интерфейс класса $1 пд1етоп принимает следующий вид. 


сТа55 $1п91етоп 


$1па1етоп& тпзтапсе(); 
операции 
ргімате: 
5іпдтесопО; 
5іпдТесоп(соп5 с $1па1етоп&); 
5іпдТесопб орегасоге(соп5с $1п91етоп&); 
-51пдТтесопО; 
} й 


6.4. Разрушение объектов класса Зіпдіеїоп 


Как указывалось выше, объекты класса 5іпдТесоп создаются по требованию при 
первом вызове функции-члена Іпѕїапсе, который определяет момент создания, но 
оставляет открытым вопрос об удалении объекта. Когда следует удалять созданный 
экземпляр, в. книге Сатта еі а). (1995) не указано, однако, по свидетельству Джона 
Влиссидеса (Райет Насте, 1998), это трудная задача. 

Действительно, если объект класса 51іпо1етоп не удален, то это не означает утечки 
памяти (тетогу [еаК). Подобная проблема возникает, когда в памяти накапливаются 
данные, ссылки на которые утеряны. Ситуация, связанная с объектом класса 5іпд1е- 
соп, совершенно иная. Здесь ничего не накапливается, и адрес объекта известен до 
самого конца работы приложения. Более того, все современные операционные систе- 
мы сами выполняют полную очистку памяти при ‘завершении программы. 
(Интересное обсуждение проблемы, что считать, а что не считать утечкой памяти, 
проведено в книге Ефеспуе С++ (Меуегѕ, 1998а).) 

Однако утечка памяти все же имеет место, более того, происходит скрытая утечка 
ресурсов (іпѕійіоиѕ гезоигсе [еаК). Конструктор класса 5іпдТесоп может запросить неог- 
раниченное количество ресурсов: сетевые соединения, обработку системных мьютек- 
сов (О8-мійе тщехез) и другие внутрипроцессные средства связи, ссылки на внепро- 
цессные (01-0{-ргосез$) СОВВА- или СОМ-объекты и т.п. 

Единственный способ избежать утечки ресурсов — удалить объект класса 5іпд1е- 
топ в момент завершения работы приложения. Вопрос заключается в том, как вы- 
брать правильный момент для удаления объекта, чтобы не возникло обращения к уже 
удаленному объекту. 

Проще всего при удалении синглтона положиться на языковые механизмы. На- 
пример, приведенный ниже код демонстрирует другой подход к реализации синглто- 
на. Вместо размешения объекта в динамической памяти и применения статического 
указателя, функция Тпзтапсе использует локальную статическую переменную (1оса| 
анс уапаЫе). 


$1п91етоп& 51ІпоТеїоп: : Тп5фапсе (> 
{ 


5сасіс 5$1па1етоп обі; 
гетиги обі; 


Эта простая и элегантная реализация была впервые опубликована Скоттом Мейерсом 
(Меуетѕ, 1996, Пет 26), поэтому мы будем называть такой класс синглтоном Мейерса. 
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Синглтон Мейерса использует некоторые скрытые свойства компилятора. Статиче- 
ские объекты, определенные в теле функции, инициализируются, когда поток управ- 
ления впервые проходит через ее определение. Не путайте статические переменные, 
которые инициализируются во время выполнения программы, с элементарными ста- 
тическими переменными, которые инициализируются статическими константами. 
Рассмотрим следующий пример. 


іп РиПО 


{ 
5зсасіс іп х = 100; 
геигп ++х; 


} 

В данном случае переменная х инициализируется до выполнения первого оператора 
программы. При первом вызове функции Ғип известно лишь, что переменная х дав- 
ным-давно равна 100. В противном случае, когда переменная инициализируется не 
константой периода компиляции, или ‘статическая переменная является объектом, 
имеющим конструктор, локальная статическая переменная инициализируется во вре- 
мя выполнения программы при первом проходе потока управления через определение 
функции. 

Кроме того, компилятор так генерирует код, что после инициализации система 
поддержки выполнения программ регистрирует переменную как предназначенную к 
удалению. Этот алгоритм можно выразить с помощью следующего псевдокода. 
(Переменные, имя которых содержит два подчеркивания, считаются скрытыми, т.е. 
они генерируются и управляются только компилятором.) 


ѕіпдЛесоп& 51па1етоп: :Іпѕїтапсе() 


// Функции, генерируемые компилятором 
ехсегп у014 __Сопѕгистѕ1іпд1етоп (мо14* тетогу); 
ехтегп моїй __реѕтгоуѕіпд1есоп() ; 
// Переменные, генерируемые компилятором 
5хасіс Боо] _іпіїіа1іғеа = Ға15ѕе; 
// БУфер, в котором хранится синглтон 
// (предполагается, что буфер вьровнен) 
5хасіс сНаг | БбибРег(5ігеовї(5іпдТесоп)1; 
ЗРО __іпітіа1іғед) 
{ 
// Первый вызов, создается объект 
// вызывается функция 51пд1етоп: : 51іпод1етоп 
// в буферной памяти _БиЁ#ег 
--Соп5 тгисЕ$1па1етоп (Фи ег) 
// регистрируется удаление 
атех1 т (__резтгоу$1па1етоп); 
—_ 111 {1а112е4 = тгие; 
} 


гетигп жхуеїптегргет  са5є«5іпдТетоп *>(_БиЁЕег); 


} 

Сердцевиной этого кода является вызов стандартной функции атехітї, позволяю- 
щей автоматически вызывать зарегистрированные ею функции при выходе из про- 
граммы в порядке 1.ЇКО (Пазі їп, йг$1 оці — последним пришел, первым ушел). (По оп- 
ределению удаление объектов в языке С++ выполняется по принципу ҒО: объекты, 
созданные первыми, разрушаются последними. Разумеется, объекты, явно управляе- 
мые с помощью операторов пем и аєТете, этому правилу не подчиняются.) Сигнатура 
функции атехі є имеет следующий вид. 
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// получает указатель на функцию. 

// возвращает 0, если работа выполнена успешно, 

// или ненулевое значение, если возникла ошибка 

Тис атехіт (уоіаС+рғип) 0); 

Компилятор генерирует функцию __реѕїгоуѕіпд1етоп, разрушающую объект класса 
$1п91етоп, хранящийся в буфере __Би{ Рег, и передает ее адрес функции агтехії. 

Как работает функция атехії? При каждом вызове этой фумкции ее параметр затал- 
кивается в закрытый стек, предусмотренный библиотекой поддержки выполнения про- 
грамм на языке С (С шайте Нгагу). При выходе из приложения система поддержки вы- 
полнения программ вызывает функции, зарегистрированные функцией атехлт. 

Вскоре мы увидим, насколько важна функция аїехі+, а также (иногда, к сожале- 
нию), насколько она тесно связана с реализацией шаблона проектирования $1па]е- 
топ на языке С++. Нравится вам это или нет, она останется в центре внимания до 
конца главы. Независимо от того, каким образом реализуется удаление объекта класса 
$1пд]етоп, для его выполнения необходима функция атехії. 

Синглтоны Мейерса предоставляют простейшие средства для удаления объектов 
класса 5іпдТетоп при выходе из программы. В большинстве случаев они работают 
безупречно. Мы хорошо их изучим, внесем в них некоторые усовершенствования и 
создадим альтернативные реализации для специальных ситуаций. 


6.5. Проблема висячей ссылки 


Чтобы конкретизировать наше обсуждение, рассмотрим пример, который мы будем в 
дальнейшем использовать дляиллюстрации разных реализаций. Как и шаблон проектиро- 
вания 51поЛетоп, этот пример легко сформулировать и понять, но трудно реализовать. 

Допустим, что в нашем приложении используются три синглтона: КеуБоага, Рі5- 
р1ау и 109. У первых двух моделей есть физические прототипы. Синглтон 109 пред- 
назначен для генерации сообщений об ошибках. Он может воплощаться в виде тек- 
стового файла либо вспомогательной консоли. 

Будем предполагать, что конструкция синглтона од вынуждает затрачивать опре- 
деленный объем дополнительных ресурсов, поэтому его лучше всего конкретизировать 
только в случае возникновения ошибки. Таким образом, если в программе нет оши- 
бок, она вообще не создает объект класса 1.09. 

Программа пересылает объекту класса 109 все ошибки, возникающие при конкре- 
тизации классов Кеубоага и рїѕр1ау, а также при уничтожении их объектов. 

Если мы попытаемся реализовать эти классы в виде синглтонов Мейерса, про- 
грамма будет работать неправильно. Например, допустим, что после успешного созда- 
ния объекта класса Кеубоага инициализация объекта класса Оі5ріау потерпела не- 
удачу. Конструктор объекта класса 0іѕр1ау создает объект класса 109, в нем регист- 
рируется ошибка, и похоже, что на этом приложение должно завершить свою работу. 
При выходе из программы вступают в действие правила языка: система поддержки 
выполнения программ разрушает локальные статические объекты в порядке, обратном 
очередности их создания. Следовательно, объект класса 1409 будет разрушен до объек- 
та класса Кеубоага. Если по некоторой причине объект класса Кеубоага не будет ус- 
пешно уничтожен, а попытается передать объекту класса од сообщение о возникшей 
ошибке, функция-член 1.04: :Іпѕтапсе невольно вернет ссылку на “оболочку” разру- 
шенного объекта класса 1049. Таким образом, поведение программы станет непредска- 
зуемым. В этом и заключается проблема висячей ссылки (деай-геѓегепсе ргоЫет). 
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Порядок создания и разрушения объектов классов кеубоага, 109 и ріѕр1ау зара- 
нее не определен. Необходимо, чтобы классы Кеубоаѓа и ріѕр1ау подчинялись пра- 
вилам языка С++ (последним создан — первым уничтожен), а класс 109 должен быть 
исключением из этих правил. Независимо от того, когда он был создан, объект класса 
109 всегда должен уничтожаться после объектов классов Кеуђбоага и ріѕр1ау, чтобы 
он мог получать сообщения об ошибках, возникающих при их разрушении. 

Если приложение содержит несколько взаймодействующих синглтонов, автомати- 
чески проконтролировать продолжительность их жизни невозможно. Нормальный 
синглтон должен по крайней мере распознавать висячие ссылки. Этого можно дос- 
тичь, отслеживая процесс разрушения объектов с помощью статической булевской 
переменной дӢеѕїгоуеа_. Начальное значение этой переменной равно Ға1ѕе. Деструк- 
тор класса 5іпдТ1етоп присваивает ей значение тгце. 

Перед тем как перейти к реализации, подведем итоги. Кроме создания объекта 
класса $1п9]етоп и возврата ссылки на него, функция-член 51іпд\етоп: :Іпѕтапсе 
должна распознавать висячую ссылку. Следуя принципу “одна функция — одна зада- 
ча”, реализуем три разные функции-члена: Сгеате, фактически создаюшую объект 
класса 5іпд\етоп, ОпоеадвеРегепсе, выполняющую обработку ощибок, и хорошо из- 
вестную функцию тп5апсе, предоставляюшую доступ к объекту класса 5іпд1етоп. 
Из всех этих функций только Іп5 сапсе является открытой. 

Реализуем класс 51пд1етоп, распознающий висячую ссылку. Во-первых, добавим в 
класс 5іп41есоп статическую булевскую переменную-член дезтгоуе4_. Она предназначе- 
на для индикации висячей ссылки. Затем изменим деструктор класса 51 пд1етоп, чтобы он 
присваивал переменной ртпзтапсе_ значение 0, а переменной дезтгоуеЧ_ — значение 
гие. Новый класс и функция ОпреайкеҒегепсе имеют следующий вид. 


// 5іпдТетоп. П 
сТа55 5іпдТетоп 


рир1іс: 
$1п9]етоп& Іпѕтапсе () 


іҒ# С!ртпзтапсе_) 


// проверка висячей ссылки 
г (аеѕтгоуеа_) 


ОпреайкеҒегепсе() ; 

е15е. 

{ 
// Первый вызов — инициализация 
Сгеате() ; 


) 


гетигп рІпѕТапсе_; 


ргімате: 
// Создаем новый объект класса 5іпдТегоп 
// и присваиваем указатель на него переменной ртизтапсе_ 
з5гагіс уоіа Сгеате() 


// Задача: инициализировать переменную рІпѕтапсе_ 


5хасіс 51пд1есоп ©һеІпѕтапсе; 
рІпѕтапсе_=&0һеІпѕтапсе; 
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// вызывается, если обнаружена висячая ссылка 
5хасіс моїй Опреадвебегепсе 0 


їһгом 51а: : гипїтіте_еггог ("обнаружена висячая ссылка"); 


уігїџа1 ~5іпд1еїоп 0) 


рІпѕсапсе_ = 0; 
деѕїгоуеа_ = їгие; 
) А 
// данные 


$1па1етоп ртпзтапсе_; 
Боо] деѕїгоуеа _; 
.. заблокированные операторы 


$}; 
//51іпаЛетоп. срр 
$1п91етоп* $1п91етоп: :ртпзтапсе_ = 0; 


Боо1 51іпд1етоп: :деѕёгоуед_ = Ға15е; 


Этот код работает! В момент завершения работы приложения вызывается деструк- 
тор класса $1п91етоп. Он присваивает переменной ртпзтапсе_ значение 0, а пере- 
менной дӢеѕїгоуеа_ — значение тгие. Если какой-нибудь объект попытается полу- 
чить доступ к уничтоженному синглтону, поток управления достигнет функции Оп- 
РеадвеРегепсе, которая сгенерирует исключительную ситуацию гипт1те_еггог. Это 
простое и эффективное решение, не требующее больших затрат ресурсов. 


6.6. Проблема адресации висячей ссылки (1): феникс 


Если описанное выше решение применить к проблеме КО! (Кеубоага, ОїзрТау, 
гоа), результат окажется неутешительным. Если деструктору класса ріѕр1ау понадо- 
бится сообщить об ошибке уничтоженному объекту класса 1049, функция-член 
109: :Іпѕїапсе сгенерирует исключительную ситуацию. Если раньше поведение при- 
ложения было непредсказуемым, то теперь оно стало неудовлетворительным. 

Нам нужно, чтобы доступ к объекту класса [од был постоянным, независимо от 
того, когда он был создан. В крайнем случае можно было бы создать объект класса 
цод вновь (после его уничтожения), чтобы получить возможность использовать его 
для генерации сообщения об ошибках в любое время. Эта идея положена в основу 
шаблона проектирования Рһоепіх 51іпд1етоп. 

Подобно легендарной птице Феникс, восстающей из пепла, такой синглтон может 
возникнуть вновь после своего уничтожения. В каждый фиксированный момент вре- 
мени по-прежнему существует лишь один экземпляр класса 5іпдіебоп (двух синглто- 
нов одновременно быть не может). Тем не менее при обнаружении висячей ссылки 
объект этого класса можно создавать вновь. Используя шаблон проектирования РНое- 
піх $1па91етоп, можно легко решить проблему КОГ: классы Кеуђоага и ріѕр1ау ос- 
таются обычными синглтонами, а класс 109 становится фениксом. 

Феникс можно легко реализовать с помощью статической переменной. При обна- 
ружении висячей ссылки новый объект класса 5іпоЛеїоп создастся под оболочкой 
старого. (В языке С++ это возможно. Память, выделенная для статических объектов, 
остается доступной на всем протяжении работы программы.) Разрушение нового объ- 
екта также регистрируется функцией атехі+. Изменять функцию Іп5 сапсе не нужно. 
Все модификации касаются только функции ОпреагВе{егепсе. 
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с1аѕѕ $1п91етоп 


... как и раньше ... 
моїд кіТТРАИоепіх5іпдТесоп(О; // Добавлено 


5 


уоча $1п91етоп: : ОпреаакеҒегепсе 0 

( 
// получаем оболочку уничтоженного синглтона 
Сгеате(); 
// Теперь указатель ртпзтапсе_ ссылается 
// на “пепел” синглтона — ячейки памяти, которые 
// ранее занимал уничтоженный синглтон. 
// На этом же месте создается новый синглтон 
пем(ртизтапсе_) 5іпдТегоп; 
// Ставим новый объект в очередь на уничтожение 
атехії(кі11РһоепіхѕіпдТеёоп); 
// изменяем значение переменной дезтгоуе4_, 
// поскольку синглтон восстановлен 
деѕігоуеа_ = Раї5е; 


} 


уоїіа 51паТетоп: :Кі11Рһоепіхѕіпо1етоп () 


// Снова все превращаем в пепел — вызываем деструктор явно. 
// переменной ртпзфапсе_ присваивается значение 0, 

// а переменной дезїгоуей — значение їгие 
ртптаисе_->-.$1п91етоп(); 


Оператор пем, используемый в функции ОпреайкеҒегепсе, называется оператором 
размещения (ріасетепі пем орегаїог). Этот оператор не выделяет память, он лишь соз- 
дает новый объект и размещает его по указанному адресу, в нашем случае — по адре- 
су, указанному в переменной ртпзтапсе_. Интересное обсуждение этого оператора 
можно найти в книге (Меуегѕ, 19986). 

В приведенном выше описании класса 51пд1еїоп добавлена новая функция кї11- 
Риоепіх5іпдТетоп. Зная, что для возрождения феникса в программе используется 
оператор размещения пем, компилятор больше не разрушает его, как обычную стати- 
ческую переменную. Мы создаем его вручную, поэтому и уничтожать его должны са- 
ми, для чего и предназначен вызов функции атехії (кі11Рһоепіхѕіпд1етоп). 

Проанализируем поток событий. При выходе из приложения вызывается деструк- 
тор класса 5іпдїетоп. Он устанавливает указатель на нулевой адрес и присваивает пе- 
ременной деѕїгоуеа_ значение тгие. Предположим теперь, что к объекту класса $1п- 
д1есоп вновь пытается получить доступ некий глобальный объект. Тогда функция Іп- 
Ѕѕ@апсе вызовет функцию Опоеадве*егепсе, которая реанимирует объект класса 
Ѕіпд1етоп и ставит в очередь вызов функции Кі11РПоепіх5іпдЛетоп. После этого 
функция Іп5 сапсе успешно возвращает ссылку на правильный объект класса $1п91е- 
топ. Теперь цикл можно повторять снова. 

Феникс гарантирует, что глобальный объект и другие синглтоны в любое время 
могут обратиться к его правильному экземпляру. Это делает феникс привлекатель- 
ным средством для создания надежных и всегда доступных объектов, таких как объ- 
ект класса 1.09. Если сделать класс оў фениксом, программа всегда будет работать 
правильно. 
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6.6.1. Проблемы, связанные с функцией аїехії 


Если сравнить код, приведенный в предыдушем разделе, с кодом из библиотеки 
Ток, обнаружится одно отличие. В библиотеке вызов функции атех1т окружен ди- 
рективой препроцессора #1 деф. 

#1#деҒ АТЕХІТ БІХЕО 

// Ставим новый объект в очередь на уничтожение 
атехітСкі11Рћоепіхѕіпд1етоп) ; 

#епаі# 

Если в программе нет директивы #аеҒіпе АТЕХГТ_ЕТХЕО, вновь созданный феникс не 
будет уничтожен. Это приведет к угечке памяти, которой мы стремимся избежать. 

Это происходит потому, что в стандарте языка С++ есть досадный пробел. В нем 
не описано, что случится, если функция регистрируется с помощью функции атехіт 
во время вызова, который является следствием другой регистрации функции атехі г. 

Чтобы проиллюстрировать эту проблему, напишем короткую тестовую программу. 


яїпсТиде <сѕта1іб> 
моіа вагО 


уоіа Ғоо() 
ѕ1а::атехіт (ваг); 
іпе таіп() 


519: : асехіт(ғоо); 


Эта маленькая программа регистрирует функцию Ғоо с помощью функции атехіт. 
Функция атех1х выполняет вызов агехіт (ваг). Этот случай не описан ни в одном 
из стандартов языков С и С++. Поскольку функция аїехіє и разрушение статиче- 
ских переменных тесно связаны друг с другом, при выходе из приложения мы теряем 
почву под ногами. Стандарты языков С и С++ внутренне противоречивы. Они утвер- 
ждают, что функция Ваг будет вызвана до функции Роо, поскольку функция Ваг за- 
регистрирована последней. Однако она не может вызываться первой, поскольку 
функция Ғоо уже была вызвана. 

Может показаться, что это слишком академическая проблема. Посмотрим на нее с 
другой стороны. Написанная выше программа была проверена на трех широко рас- 
пространенных комлиляторах. Ее поведение изменялось от просто неправильного 
(утечка ресурсов) до полного краха.? 

На поиск решения этой проблемы уйдет довольно много времени. В данный момент 
считается, что лучше всего в этой ситуации применять макросы. В других компиляторах 


2 Я обсуждал эту проблему как в группе новостей (сотр.514.с++), так и по электронной поч- 
те со Стивом Кламажем (З4еуе Катаре), председателем комитета по стандартизации языка С++ 
(АМ5ІЛ5О С++ Запдаг4$ Сотт ее). Эта проблема ему хорошо известна, и отчет об этом де- 
фекте уже направлен в соответствующие комитеты. Их можно найти на У/еб-странице 
Рир://апибіз Акицв.К/ Ле 1 /5с22/мр.2 1 /дос5// мив-іззис5.пітін3. К счастью, наиболее приемлемым 
решением этой проблемы в настоящее время считается реализация класса 5і пд1етоп, описан- 
ная здесь. Даже с функциями, вызываемыми в момент выхода из программы, функция атехі є 
работает по принципу стека, что и требуется. 
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при вторичном создании феникса в конце концов произойдет угечка памяти. Если компи- 
лятор позволяет, можно вставить в программу директиву #4е1пе АТЕХТТ_ЕТХЕО перед ди- 
рективой включения заголовочного файла $1па1етоп.Н. 


6.7. Проблема адресации висячей ссылки (1): синглтон 
с заданной продолжительностью жизни 


Феникс удобен во многих ситуациях, но имеет массу недостатков. Он нарушает 
нормальный цикл жизни синглтона, что может создать проблемы для некоторых 
пользователей. В результате выполнения цикла разрушения-восстановления синглтона 
его состояние теряется. Программист, связанный с реализацией конкретного синглто- 
на, использующий стратегию феникса (РПоепіх 5ігаїеву), должен уделить особое вни- 
мание хранению его состояния между моментами его разрушения и восстановления. 

Это особенно досадно, поскольку в ситуациях, подобных задаче КОГ,, нужно точно 
знать порядок действий. Если объект класса іод создан, он в любом случае должен 
быть разрушен после объектов классов Кеубоаг4 и рїѕр1ау. Иными словами, объект 
класса 109 должен жить дольше, чем объекты классов Кеубоага и ріѕр1ау. Нам ну- 
жен простой способ управления продолжительностью жизни разных синглтонов, и 
тогда мы сможем решить задачу КОГ, задав для объекта классса од более высокую 
продолжительность жизни, чем у объектов классов Кеубоага и ріѕр1ау. 

Однако это еще не все! Описанная выше проблема относится не только к синглто- 
нам, но и к глобальным объектам вообще. Это позволяет ввести понятие управления 
продолжительностью жизни обьектов (іопрехіќу сопігої) независимо от концепции 
синглтона. Чем большую продолжительность жизни имеет обёект, тем позже он будет 
уничтожен, причем неважно, является он синглтоном или глобальным объектом, раз- 
мещенным в динамической памяти. 

// класс $1па1етоп 

с1аѕ5 ѕотеѕіпд1етоп { ... У; 


// обычный класс 
С1аѕ5 ѕотес1аѕ5 { ... } 


Ѕотес1аѕ5* рс1ора1објест (пем ѕотес1аѕ5); 
іпо маіпО 


Ѕесі опдеуіту (&ѕотеѕіпоТ1етоп О) .Іпѕтапсе(), 5); 

// гарантирует, что объект рсТобаїобіест будет уничтожен 
// после экземпляра класса 5$оте$1иа1етоп 
5есцопдемі су (рсТораї, 6); 


} 


Функция 5етіопдеміту получает ссылку на объект любого типа и целочисленное 
значение (продолжительность жизни). 

// получает ссылку на объект, размещенный в памяти 

// с помощью оператора пем, и его продолжительность жизни 

тетр1ате «Сурепате т> 

уоіа ЅеїіопдеуітуСт* ррупојест, ипѕідпеа іпт Т1опдеміту) ; 
Функция ѕесі опдеуіту гарантирует, что объект ррупоЬјест переживет все объекты, 
имеющие меньшую продолжительность жизни. При выходе из приложения все объек- 
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ты, зарегистрированные функцией $е{гопдеу1ту, удаляются из памяти с помощью 
‘оператора Че1ете в порядке убывания продолжительности их жизни. 

Функцию 5еїтопдемі су нельзя применять к объектам, продолжительность жизни ко- 
торых управляется компилятором, например, к обычным глобальным объектам и автома- 
тическим объектам. Компилятор уже создал код для их уничтожения, и вызов функции 
Зетгопдем1 у для этих объектов может спровоцировать их повторное уничтожение. (Это 
никогда не приводит ни к чему хорошему.) Функция Ѕеїіопдеміту предназначена для 
объектов, созданных только с помощью оператора пем. Более того, применение функции 
егопдем1 ту к этим объектам отменяет вызов оператора де1ете для их удаления. 

В качестве альтернативы можно. создать объект для управления зависимостью, ко- 
торый контролировал бы зависимость между объектами. Класс ререпдепсумападег 
мог бы содержать функцию 5етререпдепсе, как показано ниже. 


сТа55 Береп4епсумападег 


риБ1їс: 
тетрТате <турепаме Т, турепаме Ц» 
уоїд Ѕетререпӣепсу(т* дерепдаепі, и& тагдет); 


}; 

Деструктор класса ререпйепсумападег уничтожал бы объекты по порядку, перед этим 
разрушая зависимости между ними. 

Проектное решение, основанное на применении класса ререпдепсумападег, имеет 
большой недостаток — оба объекта должны существовать одновременно. Это значит, что 
при попытке установить зависимость между объектами классов Кеубоага и год, например, 
придется созлать объект класса 1094, даже если в дальнейшем он совершенно не нужен. 

Для того чтобы избежать этой ловушки, можно установить зависимость между объек- 
тами классов Кеубоага и 109 внутри конструктора класса 104. Однако это создает слиш- 
ком сильную связь: объект класса Кеубоага зависит от определения класса 104 (поскольку 
он использует этот класс), а объект класса 109 зависит от определения класса кКеуроага 
(поскольку он задает зависимость между ними). Это нежелательное явление называется 
циклической зависимостью (сисшаг дереп4епсу). Оно подробно обсуждается в главе 10. 

Вернемся к парадигме продолжительности жизни. Поскольку функция 5еті опдеу- 
іу должна осторожно работать с функцией атех1т, нужно тщательно определить 
точную последовательность вызовов деструктора в следующей программе. 


с1аз$ Ѕомес1аѕ5{ ... ) 
їпо паї О 


// Создаем объект и задаем его продолжительность жизни 
ЅопеС1аѕ5* робії = пем ѕотес1аѕ5; 

зесцопдемі ту (робії, 5); 

// Создаем статический объект, продолжительность жизни 
// которого подчиняется правилам языка С++ 

5хасіс 5отеСТа55 обі2; 

// создаем другой объект и задаем еще большую 

// продожительность его жизни 

Ѕотес1аѕ5* рОБіЗ = пем 5отеСТа55; 

5етіопдемі ту (робі3, 6); 

// В каком порядке будут уничтожены эти объекты? 


В функции таіп определены как объекты, продолжительность жизни которых за- 
дается программистом, так и объекты, подчиняющиеся правилам языка С++. Опреде- 
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лить разумный порядок уничтожения этих трех объектов довольно трудно, поскольку 
кроме функции атехії у нас нет никаких средств для манипулирования скрытым 
стеком, предусмотренным системой поддержки выполнения программ. 

Тщательный анализ этих ограничений приводит к следующим проектным решениям. 


» Каждый вызов функции ѕеїіопдеміту должен сопровождаться вызовом функ- 
ции атехіт. 


• Уничтожение объектов, имеющих меньшую продолжительность жизни, должно 
предшествовать уничтожению объектов с большей продолжительностью жизни. 


• Разрушение объектов, имеющих одинаковую продолжительность жизни, долж- 
но следовать правилу языка С++: последним создан — первым уничтожен. 


В приведенном выше примере эти правила приводят к следующему порялку уничтоже- 
ния объектов: *робј1, обј2, *робјз. Первый вызов функции 5еті опдеуіту сопровождает- 
ся вызовом функции атехіт для уничтожения объекта *робј з, второй вызов, соответст- 
венно, заканчивается вызовом функции атехі тї для уничтожения объекта *р0Б]1. 

Функция Ѕеи опдеуіїу дает программистам возможность управлять продолжи- 
тельностью жизни объектов и хорошо согласуется с правилами языка С++. Заметим, 
однако, что, как и многие мощные инструменты, она может оказаться опасной. Сле- 
дует придерживаться следующего правила: любой объект, использующий объект с за- 
данной продолжительностью жизни, должен иметь меньшую продолжительность жиз- 
ни, чем используемый объект. 


6.8. Реализация синглтонов, имеющих заданную 
продолжительность жизни 


Несмотря на то что спецификация функции 5еті опдемі гу завершена, реализация не 
закончена. Функция 5ет| опдеуіту поддерживает скрытую очередь с приоритетами (ргіогіту 
диеце), не связанную с недоступным стеком функции атехіт. В свою очередь функция 
зесгопдеу1 ту вызывает функцию атех1т, всегда передавая ей один и тот же указатель на 
функцию, которая выталкивает из стека и удаляет один элемент. Все это довольно просто. 

Проблема заключается в использовании очереди с приоритетами, которые устанав- 
ливаются в соответствии с продолжительностью жизни, передаваемой функции 5Ѕеї- 
Гопдеу1ту в виде параметра. Для заданной продолжительности жизни очередь функ- 
ционирует как стек. Уничтожение объектов, имеющих одинаковую продолжитель- 
ность жизни, осуществляется по правилу “последним пришел, первым ушел”. 
Несмотря на совпадение имен, мы не можем использовать стандартный класс 
514: : ргтог1 *у_дцеце, поскольку он не устанавливает порядок следования элементов, 
имеющих одинаковый приоритет. 

Элементы данной структуры данных содержат указатели на тип 11 ѓетітетгаскег. 
Их интерфейс состоит из виртуального деструктора и оператора сравнения. В произ- 
водных классах деструктор должен замещаться. (Мы вскоре увидим, какая функция 
Сотраге для этого подходит лучше всего.) 


патеѕрасе Ргіуате 
с1аѕ5 і Ғетітетгаскег 


риб1їс: 
і есітетгаскег(ипѕідпеа іпт х) : Лопдеміту_ (х) {} 
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мігтцай ~. Ғетітетгаскег () = 0; 
Ғгіепа їп1іпе Боо] Сотраге( 
ипѕідпеа іпт 1опдеуіту, 
сопѕі і Ғетітетгаскег* р) 
{ гетигп р-»Топдемісу. > Топдеуіту; ) 
ргімате: 
ипѕідпеа Тит Топдемігу, ; 


; 
// Необходимое определение 
іп1іпе ь1Рес1тетгасКег: :~1.1 Ёетітетгаскег() {} 
} 
Очередь с приоритетами представляет собой динамический массив указателей на 
функции 11 Ғетіптетгаскег. 


патеѕрасе РГімате 


туредеї 11 Ғетітетгаскег** ТгасКегдггау; 
ехїегп ТгасКегАггау ртгасКегдггау; 
ехтегп ипѕідпеа іптє е]етепт5; 


В программе может существовать лишь один экземпляр типа ТгасКег. Следователь- 
но, при работе с массивом ртгасКегАггау возникают все те же проблемы, указанные 
выше для класса $1па1етоп. Возникает интересная проблема “курицы и яйца”: функция 
5екцопдемі ту должна быть и закрытой, и доступной одновременно. Чтобы решить эту 
проблему, функция $етьопдеу1ту использует для манипуляций с массивом ртгасКег- 
Аггау функции низкого уровня из семейства 514: :та11ос (та11ос, геа11ос и Ёкее)>. 
Таким образом, решение проблемы “курицы и яйца” перекладывается на механизм рас- 
пределения динамической памяти в языке С, гарантирующий правильную работу при- 
ложения. Следует отметить, что реализация функции 5етьопдеу1ту довольно проста. 
Она создает конкретный объект класса 11 Ёеїітетгаскег, добавляет его в стек и регист- 
рирует вызов функции атехії. 

Приведенный ниже код очень важен для обобщения. Он вводит в рассмотрение 
функторы, предназначенные для уничтожения отслеживаемых объектов. Это позволя- 
ет не использовать оператор даеїеїе для удаления объекта из динамической памяти, 
поскольку может оказаться, что объект находится в альтернативной куче или где-то 
еще. По умолчанию механизм уничтожения объекта представляет собой указатель на 
функцию, вызывающую оператор Че]ете. Эта функция называется бе1ете, а ее шаб- 
лонный параметр задает тип удаляемого объекта. 

// Вспомогательная функция для удаления объектов 


сетр1атсе «Сурепате т> 
зсгисс ре1етег 


ѕтасіс уоіа ре1ете(т* рој) 
{ Яе1ете рој; 
}; 
// конкретный объект класса 11 Ғетітетгаскег для объектов типа т 
сетр1асе <турепате Т, турепате реѕсгоуег> 
сТа55 СопсгетегіҒетітетгаске“ : рибТіс іҒесітетгаскег 


{ 


3 Фактически функция Ѕеї.опдеуіту использует только функцию 514: : геа11ос, заме- 
няющую собой и функцию та11ос, и функцию Ёгее. Если вызвать се с нулевым указателем, 
она ведет себя как функция 574: : та110с, а если задать нулевой размер, она имитирует работу 
функции 574: : Ёгее. 


Глава 6. Реализация шаблона Ѕіпдіеїоп 165 


риб11с: 

Сопсгетегї ҒетітетгаскегСт* р, 
ипѕідпеа іп Топдеміту, 
реѕтгоуег а) 
ці Ғеїітетгаскег(Лопдеуміту), 
ртгаскеа_ Ср), 

и 


~СопсгетегіҒеїітетгаскег С) 
дез єгоуег (ртгасКедй ); 


ргімате: 
т* ртгаскеа_; 
резтгоуег Яеѕїгоуег_; 
; 


\014 АСЕХІСЕПО; // необходимое объявление 


тетрТате <їурепате т, турепате реѕїгоуег> 

уоїд ѕе.опдеуітуСт* ррупобіесі, іпѕідпеа іпї Топдемігу, 
реѕтгоуег 4 = Ргіхате: : ре1етег<т> : :ре1ете) 

{ 


тгаскегдггау рмемдггау = ѕтатсіс__саѕт<тгаскегдггау> ( 
ѕ1а: : геа11ос(ртгаскегАггау, еТетепі5 + 1)); 

1Ғ С!рмемдггау) тєһгом ѕта: :Баа_а11осоО; 

Е1 Ғеїітетгаскег* р = пем Сопсгесеціїесітетгаскег 
«т, реѕтгоуег> (ррупобіест, Лопдеміту, а); 

ртгасКегАггау = рмемАггау; 

тгаскегАггау роѕ = 514: : иррег_Бочупа С 
ртгасКегАггау, ртгасКегАггау + е1етепїѕ, 
Топдемісу, Сотраге); 

5є:д::сору. Баскмагда(ро5, ртгасКегАггау + еТетепі5, 
ртгасКегдггау + е1етепї5 + 1); 

хро5 = р; 

++е1емеп?5 ; 

51а: :атехії(АТЕХЇТЕп) ; 

} 

Использование функций 514: : иррег_боџпа и 5+4: : сору_БасКмаг4 намного облегчает 
чтение и понимание этого нетривиального кода. Описанная выше функция вставляет 
вновь созданный указатель на объект класса Сопсгетец і Ғетітетгаскег в упорядоченный 
массив, на который ссылается указатель ртгасКегАггау, сохраняет порядок следования его 
элементов, а также обрабатывает ошибки и возникающие исключительные ситуации. 

Теперь цель функции Е1Рес1тетгасКег: : Сотраге проясняется. Массив, на кото- 
рый ссылается указатель ртгаскегдиеце, упорядочен в соответствии с продолжитель- 
ностью жизни объектов. Объекты с наибольшей продолжительностью жизни находят- 
ся в начале массива. Объекты с одинаковой продолжительностью жизни следуют в со- 
ответствии с очередностью их вставки. 

Функция АТЕХТТЕП выталкивает объект с наименьшей продолжительностью жизни 
(т.е. последний элемент массива) и удаляет его. Удаление указателя на объект класса 
іі Ғетітетгаскег приводит к вызову деструктора класса сопсгетегіҒетітетгаскег, 
который в свою очередь удаляет объект. 


ѕтатіс моїй АТЕХЇТЕП() 
аѕѕегі (е1етепт$ > 0 && ртгаскегАггау != 0); 


// Выбираем элемент, находящийся на вершине стека 
їҒетітетгаскег* ртор = ртгасКегАггау [е1етепт$ - 1]; 
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// Удаляем этот объект из стека. 

// ошибки не проверяются — функция геа11ос, 

// примененная к меньшему размеру памяти, 

// всегда работает правильно 

ртгаскегАггау = (ТгасКегАггау*) 514: : геа11ос(ртгаскегАггау, 
--е1етепї5) ; 

// Уничтожаем элемент 

деТете ртор; 

} 

Создавая функцию АТЕХТЕЕп, следует быть внимательным. Она должна выталки- 
вать из стека элемент, находящийся на вершине, и удалять его. В свою очередь дест- 
руктор удаляемого элемента ликвидирует управляемый им объект. Проблема заключа- 
ется в том, что функция АТЕХЇТЕп должна вытолкнуть объект из вершины стека до его 
удаления, поскольку разрушение одного объекта может повлечь за собой создание 
другого, который будет затолкнут обратно в стек. Несмотря на то что это выглядит до- 
вольно необычно, именно так развиваются события, когда деструктор класса Кеу- 
Боага пытается использовать объект класса (од. 

По умолчанию код скрывает структуры данных, и функция АСЕХІЄЕпП находится в 
пространстве имен Ргімате. Пользователи могут любоваться лишь вершиной айсбер- 
га — функцией бетгопдем1ту. 

Синглтоны с заданной продолжительностью жизни могут использовать функцию 
5етгопдем1ту следующим образом. 


сТа55 109 


а 
рибТіс: 
ЅТатіс моїй Сгеате() 


// Создаем экземпляр 

рІпѕтапсе_ = пем 109; 

// Эти строки добавлены 
зетгопдеу1 ту (*1Н1$, Топдеуіту_); 


// остальная часть реализации пропущена. 
// Функция 109: :1пѕтапсе определяется, как и прежде. 


ргімате: 
// определяем фиксированную продолжительность жизни 
5хасіс соп5ї ипѕідпеа іпт Топдем1ту_ = 2; 


Ѕтасіс 109* ртпзтапсе_; 

$; 

Если реализовать классы Кеубоаг4 и оіѕр1ау, следуя описанному выше подходу 
но задать продолжительность жизни их объектов равной 1, то объект класса 109 их 
обязательно переживет. Решает ли это проблему КРІ? Что если приложение исполь- 
зует несколько потоков? 


6.9. Продолжительность жизни объектов 
в многопоточной среде 


Синглтоны должны работать и с потоками тоже. Допустим, наше приложение только 
что начало работу, и два потока имеют доступ к приведенному ниже синглтону. 


$1па1етоп& $1па1етоп: : тпзфапсе() 


ЗРО ртизфапсе) //1 
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ріп5сапсе = пем 5іпдТесоп; // 2 


гесигп "рІп5сапсе ; // 3З 


Первый поток входит в функцию Іп5сапсе и проверяет. условие оператора 1+. По- 
скольку поток входит в функцию впервые, значение переменной рїІпѕтапсе_ равно 0. 
В таком случае поток управления достигает строки с комментарием //2 и готовится 
вызвать оператор пем. Планировщик заданий операционной системы может прервать 
первый поток в этой точке и передать управление другому потоку. 

Второй поток вызывает функцию 51п9]ехоп: :Тизфапсе() и обнаруживает, что 
значение переменной ріІп5 сапсе также равно нулю, поскольку первый поток ее еще 
не менял. До сих пор первый поток только ироверял значение переменной 
ртп$фапсе_. Теперь второй поток вызывает оператор пем, присваивает переменной 
рІпѕтапсе_ некий адрес и покидает функцию. 

К несчастью, первый поток снова приходит в сознание, вспоминает, что осталось вы- 
полнить лишь строку с комментарием //2, изменяет значение переменной ртпзтапсе_ и 
выходит из функции. Когда пыль рассеивается, оказывается, что вместо одного объекта 
класса 5іпдТесоп созданы два, причем один из них очевидно лишний. В каждом потоке 
хранится по одному объекту класса 5іпдіебсоп, и приложение погружается в хаос. И это 
только одна из возможных ситуаций! А что будет, если к синглтону имеют доступ несколь- 
ко потоков? (Представьте себе процесс отладки такой программы!) 

Опытные программисты, разрабатывающие многопоточные приложения, узнают 
здесь классическое состязание (гасе 5ішайоп). Следует быть готовым к тому, что шаб- 
лон проектирования $1п9]етоп столкнется с потоками. Синглтон относится к. гло- 
бальным ресурсам совместного использования и должен участвовать в состязании с 
другими объектами, решая проблемы нескольких потоков. 


6.9.1. Шаблон блокировки с двойной проверкой 


Всестороннее обсуждение многопоточных синглтонов впервые было проведено Дугла- 
сом Шмидтом (ПРоизаз Ѕсһтіаї, 1996). В этой же статье было описано очень остроумное 
решение, названное шаблоном роиБ1е-сһескей і оскіпо (блокировка с двойной провер- 
кой), предложенное Дугласом Шмидтом и Тимом Харрисоном (Тіт Нагтіѕоп). 

Очевидное решение существует, но выглядит непривлекательно. 


$1191 етоп& 51п91етоп: :Іп5 сапсе 0 


// титех_ — объект мьютекса. 

// мьютексом управляет объект класса цосК 
ьосК диагда(митех. ); 

1Е (!ртифапсе_) 


ріп5гапсе = пем 51пд1етоп; 


геёцгп *рІпѕтапсе_; 
} 
Класс 1осК — это классический обработчик мьютексов (детали описаны в приложе- 
нии). Конструктор класса іоск захватывает мьютекс, а деструктор освобождает его. 
Пока мьютекс митех_ захвачен, другие потоки, пытающиеся завладеть им, ожидают 
своей очереди. 
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Это освобождает нас от состязания: пока поток присвоен объекту ртпзфапсе_., ос- 
тальные останавливаются в конструкторе диага. Когда другой поток пытается захватить 
блокировку, он обнаруживает уже проинициализированную переменную рІпѕтапсе_, и 
все проходит гладко. 

Однако правильное решение не всегда оказывается приемлемым. Неудобство за- 
ключается в недостатке эффективности. Каждый вызов функции-члена Іп5 -апсе вле- 
чет за собой блокировку и освобождение объекта синхронизации, хотя состязание за 
ресурсы возникает, образно говоря, один раз в жизни. Эти операции обычно очень 
затратны. Их стоимость намного превышает стоимость выполнения простой проверки 
ЗРО ріп5 сапсе). (В современных системах время, затрачиваемое на проверку и ветв- 
ление, обычно отличается от времени, онша на блокировку критических разде- 
лов, на несколько порядков.) 

Для того чтобы избежать дополнительных аата можно было бы предложить сле- 
дующее решение. 


ЅіпоТетопё& $1па91етоп: :Іпѕ+апсе() 
1+ С!рІпѕ+апсе_) 


іоск диага(титех_) ; 
рІпѕтапсе_ = пем $1п91етоп; 


гетигп *ртпзтапсе_; 


Теперь дополнительных затрат нет, однако осталось состязание за ресурсы. Первый по- 
ток проходит проверку 11, однако прямо перед входом в синхронизированную часть кода 
планировщик заданий операционной системы прерывает его и передает управление дру- 
гому потоку. Второй поток также проходит проверку 1# (и, естественно, обнаруживает ну- 
левой указатель), входит в синхронизированную часть кода и выполняет ее. После повтор- 
ной активизации первый поток также входит в синхронизированную часть, но слишком 
поздно — снова создаются два объекта класса $1па1етоп. 

Кажется, что эта головоломка не имеет решения, но оказывается, что существует 
очень простое и элегантное решение. Оно называется шаблоном роиБ1е-Сһескеай 
іоскіпд (блокировка с двойной проверкой). 

Идея проста: проверяем условие, входим в синхронизированный код, а затем про- 
веряем это условие снова. Указатель оказывается либо уже проинициализированным, 
либо нулевым. Ниже приведен код, позволяющий разобраться и оценить преимущест- 
ва шаблона блокировки с двойной проверкой. В нем действительно проявляется кра- 
сота программирования. 


$1п91етоп& $1па1етоп: : Іпѕтапсе () 


1+ С ріп5 єапсе) // 1 
// 2 

Сиага тусиага(ПоскК ); // 3 
іЁ С!рІпѕтапсе_) // 4 


ртпзтапсе_ = пем $1па1етоп; 


} 


гекигп *рІпѕ+апсе_; 
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Допустим, что поток управления входит в зону неопределенности (строка 2). В эту 
точку могут войти сразу несколько потоков. Однако в синхронизированный раздел 
входит только один поток. В строке 3 неопределенности вообще нет. Здесь все ясно: 
указатель либо полностью проинициализирован, либо не проинициализирован вооб- 
ще. Первый поток, который входит в этот раздел, инициализирует переменную, а все 
остальные не пройдут проверки на строке 4 и ничего не создадут. 

Первая проверка быстрая и грубая. Если объект класса 5іпд1ебоп доступен, вы. его 
получаете. Если нет, необходимы дальнейшие исследования. Вторая проверка мед- 
ленна и точна: она сообщает, действительно ли проинициализирован синглтон, или 
это должен сделать поток. В этом и заключается суть блокировки с двойной провер- 
кой. Теперь мы получаем большое преимущество: скорость доступа к синглтону высо- 
ка настолько, насколько позволяет сам объект. Однако во время создания объекта 
класса 5$1п91етоп состязание больше не возникает. И все же... 

Программисты, имеющие очень большой опыт работы с потоками, знают, что да- 
же шаблон блокировки с двойной проверкой, правильный на бумаге, не всегда хоро- 
шо работает на практике. В некоторых симметричных мультипроцессорных системах 
(с так называемой релаксированной моделью памяти) порции информации загружа- 
ются в память одновременно, а не последовательно. Эти порции записываются по 
возрастанию адресов, а не в хронологическом порядке. Из-за такого способа упорядо- 
чения записей память, просматриваемая одним процессором, может выглядеть так, 
будто порядок операций, выполненных другим процессором, был неправильным. На- 
пример, присваивание значения переменной ртпзтапсе_ может выполняться до за- 
вершения полной инициализации объекта класса $1па1етоп! Таким образом, увы, 
шаблон блокировки с двойной проверкой оказался непригодным для таких систем. 

В заключение следует заметить, что перед реализацией шаблона роиБ1е-Сһескей 
уосКіпд нужно просмотреть документацию компилятора. (Тогда его можно назвать шаб- 
лоном Тгір1е-Сһескеа цосКіпд (блокировка с тремя проверками).) Обычно операцион- 
ная система предоставляет альтернативные, машинно-зависимые средства решения про- 
блемы параллелизма, например, барьеры, упорядочивающие доступ к памяти (тетогу Баг- 
пегѕ). По крайней мере, поставьте перед переменной рІпѕтапсе_ спецификатор мо1ат11е. 
Хороший компилятор должен генерировать правильный код вокруг таких объектов. 


6.10. Сборка 


В этой главе обсуждаются разные реализации класса 5ігд1етоп, выявляются их 
относительные преимущества и недостатки. Не следует думать, что в результате мы 
сможем прийти к универсальному решению, поскольку каждая задача предъявляет к 
реализации класса 51іпд1етоп свои требования. 
| Шаблонньй класс $1п91етопно1аег, определенный в библиотеке І окі, представляет 
собой контейнер для синглтонов, позволяющий применить шаблон проектирования 
5іпдТесоп. Следуя шаблону проектирования, основанному на применении стратегий 
(глава 1), класс 5іпдТесопноїдаег разработан как специализированный контейнер для 
объектов класса 51іпд1еїоп, определенного пользователем. При использовании класса 
5іпдТегопноїдег программист получает все необходимые функциональные возможно- 
сти и может создавать свой собственный код. В крайнем случае придется все переделать 
заново (поэтому этот случай и называют крайним). 

В этой главе рассмотрено несколько тем, практически не связанных друг с другом. Как 
же теперь реализовать класс 5іпд1етоп, не раздувая размер программы? Для этого нужно 
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тщательно разложить шаблон $1п91етоп на стратегии, как показано в главе 1. Разложив 
класс $1п91етопно14ег на несколько стратегий, можно реализовать все варианты, рас- 
смотренные выше, с помощью кода, состоящего из небольшого количества строк. Исполь- 
зуя конкретизацию шаблонов, можно отобрать желательные свойства и пренебречь не- 
нужными. Это очень важно: реализация класса 5іпд1есоп не универсальна. Используются 
лишь те свойства, которые в итоге будуг включены в сгенерированный код. Кроме того, 
реализация оставляет возможности для изменения и расширений. 


6.10.1. Разложение класса ЅіпдіеїопНо!аег на стратегии 


Начнем с выделения стратегий из описанной выше реализации. В ней можно 
идентифицировать вопросы, связанные с созданием объекта, его продолжительностью 
жизни и потоками. Это три наиболее важных момента в разработке синглтонов. Рас- 
смотрим соответствующие стратегии. 


1. Стратегия Сгеасіоп. Синглтон можно создать разными способами. Обычно для 
создания объекта стратегия Сгеаїіоп использует оператор пем. Выделение про- 
цесса создания объекта в виде отдельной стратегии существенно, поскольку это 
позволяет создавать полиморфные объекты. 


2. Стратегия Е1етлте. Различаются следуюшие стратегии продолжительности 
жизни объектов. 


2.1. Правила языка С++ — последним создан, первым уничтожен. 

2.2. Феникс. 

2.3. Синглтон с заданной продолжительностью жизни. 

2.4. Бессмертный синглтон (объект, который никогда не уничтожается). 


3. Стратегия ТАгеаЧ1 пумодеї. Синглтон может работать в режиме одного потока, в 
стандартном многопоточном режиме (с мьютексами и блокировкой с двойной 
проверкой) или использовать платформно-зависимую потоковую модель. 


Все реализации класса Ѕ1іпд1етоп должны гарантировать уникальность объекта. 
Это условие не влияет на выбор стратегии, поскольку его невыполнение нарушает оп- 
ределение синглтона. 


6.10.2. Требования, предъявляемые к стратегиям класса Зто!еюпНо!аег 


Определим необходимые ограничения, накладываемые классом 5іпдТесопноїдевг 
на свои стратегии. 

Стратегия Сгеатіоп должна создавать и уничтожать объекты, следовательно, она долж- 
на содержать две соответствующие функции. Таким образом, если класс Сгеатог<т> со- 
гласован со стратегией Сгеатіоп, он должен содержать вызовы следующих функций. 


Т* робі = сгеатог<т> ; : сгеате(); 
Сгеатог<Т> : :Везтгоу (робі); 


Обратите внимание на то, что функции Сгеате и безтгоу должны быть статическими 
членами класса Сгеатог. Класс 5іпдТетоп не содержит объект, имеющий тип сгеатог, — 
это не позволило бы решить проблемы, связанные с его продолжительностью жизни. 
Стратегия Е1Тет1те, по существу, должна планировать разрушение объекта класса 
5іпдТесоп, созданного стратегией Сгеатіоп. Функциональные возможности страте- 
гии і Ёетіте выражаются в ее способности разрушать объект класса 51іпо1еїоп в за- 
данный момент времени. Кроме того, стратегия Е1Фет1те решает, какие действия 
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следует предпринять, если приложение нарушает правила языка С++, определяющие 
продолжительность жизни синглтона. 


• Если синглтон нужно уничтожить, следуя правилам языка С++, стратегия 
+1 бесіте применяет механизм, аналогичный функции аїехії. 


• Для феникса стратегия і іҒетіте продолжает использовать механизм, анало- 
гичный функции атехітї, но допускает восстановление синглтона. 


» Для синглтона с заданной продолжительностью жизни стратегия 1 і Ғеїіте вы- 
зывает функцию 5еті опдеуіту, описанную в разделах 6.7 и 6.8. 


• При неограниченной продолжительности жизни синглтона стратегия 11 Ғетіте 
не предпринимает никаких действий. 


В заключение отметим, что стратегия 1 Ғетіте содержит две функции: ѕсһеаи1е- 
резтгисЕ Топ, задающую время уничтожения объекта, и ОпреаавеҒегепсе, регламен- 
тирующую поведение программы при обнаружении висячей ссылки. 

Предположим, что стратегия 1 і Ёетіте и. классом 11 Ёетіте<т>. Тогда 
имеют смысл следующие выражения: 


моїд (*рреѕ сгиссіопЕипссіоп) (); 


Іі Ғетіте<т> : : ѕ5сһейи1ереѕтгисттоп (рреѕ ЕгисїіїопғипсТіоп) ; 

ії Ғетіпте<т> : : ОпреаавеҒегепсе () ; 

Функция-член ѕЅсһейиЛереѕігисїііоп получает указатель на функцию, уничто- 
жающую объект. Таким образом, стратегию 1 іҒетіте можно использовать вместе со 
стратегией Сгеаїіоп. Не забывайте, что стратегия і1Ғеїіте не связана с методами 
уничтожения объектов, которые относятся к стратегии Сгеаїіоп. Единственное пред- 
назначение стратегии і Ёетіме — определять, когда объект должен быть уничтожен. 

Функция опреадвеРегепсе генерирует исключительные ситуации всегда, за ис- 
ключением ситуаций, в которых задействован феникс. В последнем случае стратегия 
не предусматривает никаких действий. 

Стратегия ТИгеад1пдмоде] описана в приложении. Класс 5іпаТесопноїдег под- 
держивает блокировку только на уровне классов, но не на уровне объектов. По этой 
причине в любой момент времени существует лишь один синглтон. 


6. 10.3. Сборка класса Зто!ейопНо4ег 


Начнем определение шаблонного класса 51іпд1етопно1аег. Как указывалось в главе 1, 
для каждой стратегии предназначен отдельный шаблонный параметр. Кроме того, мы пре- 
дусмотрим шаблонный параметр Т, определяющий разновидность синглтона. Шаблонньй 
класс $1п9]етопно]4ег сам по себе не определяет синглтон. Он лишь задает его поведе- 
ние и способы управления им с помощью уже сушествуюшего класса 51пд1етоп. 

тетр1ате 

< 

сТа55 т, 
сетрТасе <с1аѕѕ> сТа55 СгеаїіопРо1ісу = Сгеатеиѕіпдмем, 


Сетр1ате <с1аѕѕ> с1а55 11 ҒеіітеРо1ісу = реаҒаи1 11 есіте, 
сетрТасе «сТа55» с1аѕ5 Тһгеааіпдмоде1 $1па1етИгеадед 


> 
сТа55 5іпдТесопної дег 


риб'їс: 
5хасіс Т& іп5тапсей); 
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ргімаге: З 
// Вспомогательные функци 
ѕТатіс уоіа оеѕїгоіпдѕіпд1етоп() ; 
// Защита 
5іпдТесопноїдегО; 


// Данные 

туреде{ тігеадіпдмоде?«Т»: :МоТатіТеТуре тпзтапсетуре; 
5сасіс Тпзтапсетуре*“ ртпзтапсе_; 

зтае1с Боо] дезегоуе4_; 

$}; 

Вопреки ожиданиям, переменная экземпляра не относится к типу Т*. На са- 
мом деле она имеет тип ТНгеа41пдмоде1<т> : :Уо]ат11етуре*. Тип тИгеадїіпд- 
мМодеї«ть::УоТасіТетуре расширяет тип Т или тип моїасіїе Т в зависимости от 
фактически применяемой модели потоков. Спецификатор моТаєіїе применяется к 
типам для того, чтобы сообщить компилятору, что значение данного типа может из- 
меняться несколькими потоками. Зная это, компилятор не станет выполнять некото- 
рые виды оптимизации (например, запись значений во внутренние регистры), по- 
скольку это может привести к ошибочной. работе потоков. В целях безопасности 
можно было бы объявить переменную ртпзТапсе_ с типом уо1аті1е т*. Это сработа- 
ет при использовании многопотокового кода (этот факт следует предварительно про- 
верить по документации), но бесполезно в программе с одним потоком. 

С другой стороны, в модели с одним потоком следует стремиться к оптимизации 
программы, так что тип Т* был бы для переменной рІпѕтапсе_ наилучшим выбором. 
По этой причине тип для переменной ріпѕтапсе_ выбирается стратегией ТИгеа91па- 
моае1. Если эта стратегия является однопоточной, определяется тип Ууо1атсі1етуре. 


тетр1ате «сТа55 Т> с1аѕѕ 5іпдТетігеадед 


рчЬ11с: 
хуредеї т моТасіТетуре; 
у 
Многопоточная стратегия связывала бы параметр Т с типом уо1аті1е. Детали много- 
поточных моделей описаны в приложении. 
Определим теперь функцию-член Іпѕтапсе, в которой объединяются все три стратегии. 


тетр1ате <...> 
те 5іпдТесопноїдег«...»::ІпзсапсеО 


1 
1Р (!рІпѕсапсе_) 
хурепате ТИгеадіпдмодеї«Т»::їосК диага; 
1? (!рІпѕтапсе_) 
{ 
1Р (дезтгоуед_) 
{ 
1 Гесіперої і сухтТ»: : ОпреайвкеҒегепсе() ; 
деѕїгоуеа_ = Ға1ѕе; 
ртпзфапсе_ = Сгеатіопро1ісу<т> : : Сгеате() ; 
1 ҒесітеРо1ісу<т> : : ѕсһеаи1еса11 (&0еѕтгоуѕіпд1етоп) ; 
} 
гетигп *рІпѕтапсе_; 
} 
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Функция тпзтапсе является единственным открытым членом класса 5іпдТетоп- 
но1аег. Она представляет собой оболочку классов СгеатТопРо11су, 11 ЁетітеРо1ісу и 
Тигеад1 помоде1. Класс ТИгеад1пдмо4е1<т> содержит внутренний класс 1оск. На про- 
тяжений жизни объекта класса госКк все другие потоки, пытающиеся создать объект 
этого типа, блокируются. (Детали описаны в приложении.) 

Функция реѕтгоуѕіпд1етоп просто разрушает объект класса 5іпд1етоп, очищает 
занятую память и присваивает переменной йеѕтгоуеа _ значение тгие. Класс 5іпд1е- 
топно1аег никогда не вызывает функцию без5 гоу5іпдїесог, а лишь передает ее ад- 
рес функции-члену 11 Гесітерої і су«Т» : :5сСпедиТере5 сгиссТоп. 


тетр1ате <...> 
моїд 5іпдТесопноТдег«...»::0е5 сгоу5іпдТесоп (0 


аз5егт( !Чезтгоуе4_); 
СгеасіопРої ісу«Т»: : Везтгоу (ріп5 апсе ); 
рІпѕїапсе_ 0; 

деѕтгоуеа_ = їгие; 


Класс 5іпдТесопноїдег передает переменную рІпѕїапсе_ и адрес функции ре- 
$тгоу$1ид1етоп классу 11Ғетітеро1ісу<т>, предоставляя ему информацию о пове- 
дении объекта: подчиняется он правилам языка С++ или является фениксом, имеет 
заданную продолжительность жизни или бессмертен. 


1. Правила С++. Функция 11 Ғетітеро1ісу<т»> : : Ѕ$сһейиЛ1ереѕстгистіоп вызывает 
функцию аїехіт, передавая ей адрес функции беѕїгоуѕіпо1етоп. Функция Оп- 
реадкеїегепсе генерирует исключительную ситуацию 514: : 1091 с_еггог. 


2. Феникс. Совпадает с предыдущей стратегией, только функция Опреадве{егепсе 
не генерирует исключительную ситуацию. Поток управления класса 51іпд1етоп- 
но1аег продолжает выполнение программы и воссоздает объект вновь. 


3. Синглтон с заданной продолжительностью жизни. Функция 11Ёес1терРо- 
1їсухТ»: :5спедиТерез5ссгиссітоп вызывает функцию 
сетгопдем1 ту (дестопдеу1 су (ріп5 сапсе)). 


4. Бессмертный синглтон. Функция 11 Ёетсітеро1їсу<т> : : зспеди]ебезстгист1оп 
` не выполняет никаких действий. 


Класс $1по1етопно]дег решает проблему висячей ссылки в соответствии со стратегией 
11 Ғетітеро11ісу. Она очень проста: если функция 51іп1аесопно1аег: :Іпѕтапсе обнару-. 
живает висячую ссылку, она вызывает функцию 11 Ғесітеро1ісу: :Опреадкебегепсе. Ес- 
ли функция ОпреаакеҒегепсе возвращает управление, функция Іп5сапсе воссоздает но- 
вый экземпляр. В заключение функция Опреадвебегепсе должна сгенерировать исключи- 
тельную ситуацию или прекратить выполнение программы, если синглтон не является 
фениксом. 

Вот и вся реализация класса $1пд1етопно1аег. Разумеется, теперь основная часть 
работы перекладывается на три стратегии. 


6.10.4. Реализации стратегий 


Разложить класс на стратегии трудно, зато потом их легко реализовывать. Рассмотрим 
классы, реализующие стратегии для распространенных разновидностей синглтонов. В 
табл. 6.1 приведены классы стратегий для класса $1па1етопно1аег. Классы стратегий, вы- 
деленные курсивом, являются шаблонными параметрами, задаваемыми по умолчанию. 
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Таблица 6.1. Стратегии класса 5іпдіеїопНо!аег 


Стратегия Шаблонный класс Комментарии 
Сгеасіоп сгеаїейя іпумем Создает объект с помощью оператора пем и 


конструктора по умолчанию 


Сгеатецз1пдма]Тос Создает объект с помощью функции 
$14: :та]1ос и конструктора по умолчанию 
Сгеатеѕтатіс Создает объект в статической памяти 
Сї Ғетіте реёаи7 сі їТеттіте Управляєт продолжительностью жизни 


объекта в соответствии с правилами языка 
С++. Для выполнения задания вызывает 
функцию атехії 


РНоеп1х51па]1етоп Выполняет то же самое, что и класс 
Фефаи1тЕ1 Ғетіте, но допускает 
воссоздание объекта класса 51 п41етоп 


51191 етопм1 {Аьопдеу1{У | Задает продолжительность жизни объекта 
класса 51іпд1етоп. Предполагается, что в 
пространстве имен существует функция 
сет_опдеуіту, которая, будучи вызванной 
с параметром ртпзтапсе_, возвращает 
продолжительность жизни синглтона 


Мореѕї гоу Не допускает уничтожения объекта класса 
$119] етоп 
Тигеадіпд- 5779 7етргеадед Детали описаны в приложении 
моде] ° 
СТа55 еме1іоскаБ1е 


Осталось только узнать, как использовать й расширять зтот маленький, но доволь- 
но мощный шаблонный класс $1п9Тетопно1 4ег. 


6.11. Работа с классом 5іпдіеїопНоаїег 


Шаблонный класс 5іпдТетопноїдаег не требует от приложения специфических 
функциональных возможностей. Он просто предоставляет специальные средства для 
работы с синглтонами в других классах — в нашем коде они обозначены буквой Т. 
Класс Т мы будем называть клиентским (сПепи с1а). 

В клиентском классе слелует предусмотреть все меры для предотвращения непред- 
намеренного создания и уничтожения объектов: конструктор по умолчанию, конст- 
руктор копирования, оператор присваивания, деструктор и оператор взятия адреса 
должны быть закрытыми. 

Прелприняв эти меры, нужно объявить дружественным класс Сгеатог. Превентивные 
меры и объявление Ёгіепа — вот и все изменения, которые необходимо внести в класс, 
работающий с классом $1пд1етопно14ег. Отметим, что все эти изменения совершенно не 
являются обязательными и представляют собой компромисс между неудобствами настрой- 
ки сушествуюшего кода и риском возникновения фиктивных объектов. 

Проектные решения, касающиеся работы со специальной реализацией класса 51п- 
91етоп, отражаются в определении типа, как показано ниже. Передавая признаки и 
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опции при вызове некоторой функции, вы передаете их определению типа, выбирая 
соответствующее поведение объектов. 

с1а55 А { Е 

хуредеї $1п9]етопно]4ег<А, Сгеатеу$1пдмем> 5іпдЛед; 

// теперь можно использовать функцию 51іпдїед: : Іпѕїћапсе() 

Описать синглтон, возвращающий объект производного класса, довольно просто. 
Для этого достаточно внести изменения в класс стратегии Сгеатог. 


с1аѕ5 А {... }; 
сТа55 Регтуе4 : риб11слд { ... У; 


тетрТафе «сТа55 Т> $%гисЕ Мусгеатог : рибТіс Сгеатеу$1паМем<т> 
5сасіс Т* сгеате() 
і гетигп пем регімеа; 

}; 

туредеї 5іпдТетопноїдег«д, Ѕ?аїїсА1Л1осатог, МуСгеатог» 51пд1ед; 


Кроме того, можно задать параметрь конструктора, использовать другую стратегию 
распределения памяти или настроить класс 5іпдТетоп на каждую отдельную страте- 
гию. Это позволяет точно настроить класс 51п91етфоп, сохранив все его функциональ- 
ные возможности, предусмотренные по умолчанию. 

Класс стратегии $1п91етопм1 ЕРьопдем1еу полагается на определение функции 
Сеш опдеуіїу, находящейся в пространстве имен. Ее определение может выглядеть 
следующим образом. 


іп1іпе ипѕідпеа іп Сей опдеуіту(А*) { гефиги 5; } 


Это нужно, только если вы используете класс 5Ѕ51іпо1еміїћі_ опдеуіту в определении 
типа 51по1ед. 

Наши экспериментальные реализации испытывались на задаче КР, Теперь она 
решается с помощью шаблонного класса $1п91етоп. Разумеется, эти определения 
должны находиться в соответствующих заголовочных файлах. 

с1аѕ5 кеубоагаттр! { ... }; 


с1аѕ5 ОізрТауттрі { ... }; 
сТбТа55 годттр1 {... У; 


іп1іпе ипѕідпеа 1пЕ Се опдечіту(кеубоагаїітр1*) { гекигп 1; } 
іп1іпе ипѕідпеа іп Сей опдеуїту(ріѕрТ1ауітр1*) { геїигп 1; } 
// Объекты класс 109 живут дольше 

іпііпе ип5ідпед іпс бетгопдеу1ту(Стодттр1*) { гетигп 2; } 


туредеї $1пдТетопно]дег<кеуБоагаттр1, 5іпдіесопимі тИгопдеу1ту> Кеуроага; 
хуредеї 5іпдТегопної4ег«Оізріауїтрі, 5іпдТесопмі єп опдеміту» ОізрТау; 
туредеї 51по1етопно1дег<і_одІтр1, 51 по1етопмітћі опдеуіїу> 1094; 


Учитывая сложность задачи, описанное решение является достаточно простым и 
очевидным. 


6.12. Резюме 


В начале главы была описана наиболее популярная реализация класса 51п91етоп 
на языке С++. Предотвратить тиражирование синглтонов довольно просто, поскольку 
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для этого существует хорошая языковая поддержка. Сложнее всего управлять продол- 
жительностью жизни синглтона, особенно процессом его уничтожения. 

Распознать попытку доступа к уничтоженному синглтону просто. Для этого не 
требуются дополнительные ресурсы. Это распознавание должно быть неотъемлемой 
частью реализации класса 51по1еїоп. 

В главе рассмотрены четыре основные вариации на эту тему: синглтон, управляе- 
мый компилятором, феникс, синглтон с заданной продолжительностью жизни и бес- 
смертный синглтон. У каждого из них есть свои преимущества и недостатки. 

Шаблон проектирования 5іпдТесоп тесно связан с моделями потоков. Шаблон 
роцьТе-Спескіпу цоскіпд позволяет создать синглтоны, гарантирующие безопасную 
работу потоков. 

В заключении перечислены и классифицированы основные стратегии и выполнена 
соответствующая декомпозиция класса 51іпд1етоп. В классе ѕ51іпо1етоп выделены три 
основные стратегии: Сгеатіоп, 1 есіме и тһгеааіпдмоае1. Эти стратегии сопряже- 
ны в определении класса $1п91етопно14ег с четырьмя параметрами (клиентский тип 
плюс три стратегии), которые покрывают все возможные комбинации проектных ре- 
шений. 


6.13. Краткое описание шаблонного класса 
ЗшаеоптпНо ег 
• Определение класса 51п91етопно14ег имеет следующий вид. 


тетріабе < 
с1аѕ5 Т, 
тетр1ате <с1аѕѕ5> с1аѕѕ СгеатіопРо1ісу = Сгеатеуѕіпдмеуу, 
Тетр1ате <с1аѕ5> с1аѕ5 1іҒетітеР1ісу = беЁРаи1 Е їҒетіте, 
хетріате <с1аѕѕ> с1аѕѕ тһћгеааіпомоае1 = ѕіпд1етһгеайеа 
> 
с1аѕ5 $1п91]етопно]дег; 


• Шаблонный класс 51п91етопно1аег конкретизируется путем передачи клиент- 
ского класса в качестве первого шаблонного параметра. Различные проектные 
варианты выбираются с помощью комбинирования четырех остальных пара- 
метров. 

с1аѕ5 мус1аѕѕ {... }; 
хуредеї 51п91есоп<Мус1аѕ5, Сгеаїтеѕтаїіс> 
му5іпд1еСТа55; 

• Нужно определить конструктор по умолчанию или использовать для создания 
синглтона класс, отличающийся от стратегии Сгеаїог. 


• Готовые реализации трех основных стратегий описаны в табл. 6.1. При необхо- 
димости к ним можно добавить свои собственные классы стратегий, ориенти- 
рованные на новые ограничения. 
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ИНТЕЛЛЕКТУАЛЬНЫЕ УКАЗАТЕЛИ 


Интеллектуальным указателям посвяшены миллионы строк кода и сотни книг. 
Благодаря тому, что в интеллектуальных указателях переплелись многие синтаксиче- 
ские и семантические проблемы, они стали одной из самых популярных, интересных 
и мощных идиом языка С++. В этой главе обсуждаются все аспекты интеллектуаль- 
ных указателей (от простейших до самых сложных), а также наиболее распространен- 
ные ошибки, совершаемые программистами при их реализации. 

Интеллектуальные указатели -- это объекты языка С++, имитирующие обычные 
указатели с помощью реализации оператора -> и унарного оператора *. Кроме того, 
они часто скрытно выполняют полезные задания (например, осушествляют управле- 
ние памятью или блокировку), освобождая приложение от детального контроля за 
объектами, на которые они ссылаются. 

В главе не только обсуждаются интеллектуальные указатели, но и реализован шаб- 
лонный класс 5тагіРЕг. Этот класс разработан на основе стратегий (глава 1). Он 
безопасен, эффективен и легок в использовании. 

Здесь рассмотрены следующие вопросы. 


• Преимущества и недостатки интеллектуальных указателей. 
® Стратегии управления владением. 

е Неявные преобразования. 

• Проверки и сравнения. 

• Многопоточность. 


В главе описан обобщенный шаблонный класс ѕтагтріг. В каждом разделе рас- 
сматривается отдельная проблема, связанная с реализацией этого класса, а полная 
сборка класса выполняется в конце главы. Программисту мало знать, как устроен 
шаблонный класс 5тагЕРХг, нужно еще уметь использовать, изменять и расширять 
его в своих программах. 


7.1. Сто первое описание интеллектуальных указателей 


Что такое интеллектуальный указатель? Это класс, имитирующий синтаксис и се- 
мантику обычного указателя и выполняющий много другой полезной работы. По- 
скольку интеллектуальные указатели, ссылающиеся на объекты разных типов, имеют 
много общего, они почти всегда реализуются в виде шаблонов. 


хетрТасе <с1аѕѕ т> 
с1аѕѕ ѕмагірЕг 


{ 

руб] 1с: 
ехр1ісіт 5тагсРЕГОТХ роїпсее) : ротптее_(ро1птее); 
этагЕРЕГ& орегатог=(сопѕї Ѕтагтрег& отПпег); 
—стагеРЕГ(); 
те орегатог*() соп5г 


{ 


гетигп *роіптее_; 


} 
Т* орегатог->() сопѕт 
{ 


гетигп роїптее ; 


а 
та роіптее_; 

$; 

Шаблон ‘тагЕРЕГ<Т> хранит указатель на тип Т в переменной-члене ро1птее_. 
Именно так поступает большинство интеллектуальных указателей. В некоторых слу- 
чаях в этих классах предусматривается некоторая дополнительная обработка данных, а 
сам указатель вычисляется на лету. 

Синтаксис и семантика обычных указателей имитируются следующими операто- 


рами шаблонного класса ѕтагтртк. 
с1аѕѕ мійддет 


ручБ11с: 
\014 Еип(); 
}; 


Ѕмагїірег<мї адет> зр(пем міддет) ; 

зр->Рий О; 

(#5р>.кипО; 

Помимо определения класса 5р, класс Зтаг®Ртг ничем не отличается от обычного 
указателя. В этом и заключается существо интеллектуального указателя: обычные ука- 
затели можно заменить интеллектуальными, не внося коренных изменений в про- 
грамму. Таким образом, можно легко получить дополнительные преимущества. Воз- 
можность практически не изменять код при использовании интеллектуальных указа- 
телей в больших приложениях — очень привлекательное и важное свойство. Однако, 
как мы увидим ниже, не все так просто. 


7.2. Особенности интеллектуальных указателей 


Может возникнуть вопрос: “Зачем нужны интеллектуальные указатели?”. Какую выго- 
ду можно извлечь, заменив обычные указатели интеллектуальными? Все очень просто. 
Интеллектуальные указатели имеют семантику значений, а простые указатели — нет. 

Объект, имеющий семантику значений, — это объект, который можно копировать и 
присваивать. Числа типа іп? — прекрасный пример. Их можно свободно создавать, копи- 
ровать и изменять. Указатель, который применяется для перемещения по буферу, также 
имеет семантику значений — он инициализируется адресом первой ячейки буфера и пе- 
ремещается по нему вперед, пока не достигнет конца. По пути значения этого указателя 
можно копировать в другие переменные, сохраняя промежуточные результаты. 
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Однако работать с указателями на объекты, созданные с помощью оператора пем, 
нужно совсем иначе. Допустим, мы написали следующее выражение. 

м1адет* р = пем міддет; 

В этом случае переменная р не только указывает на объект класса жі адет, размещен- 

ный в памяти, но и владеет им. Это значит, что при выполнении оператора ӣе1ете р 

соответствующий объект класса міадет будет уничтожен, а выделенная для него па- 

мять освобождена. Таким образом, приведенный ниже код окажется неверным. 
итадет* р = пем міддет; 

р = 0; // Присваиваем указателю р нечто иное 
Это происходит потому, что мы теряем владение объектом, на который ранее ссылал- 
ся указатель р, и не имеем возможности вернуть его. Это приводит к утечке ресурсов. 

Более того, при копировании указателя р в другую переменную компилятор не пе- 
редает ей автоматически владение участком памяти, на который ссылается указатель. 
Вместо этого в программе появляются два указателя, содержащих адрес одного и того 
же объекта. Это нежелательно, поскольку может привести к повторному удалению 
уже удаленного объекта (со всеми вытекающими катастрофическими последствиями). 
Следовательно, указатели на динамически размещаемые объекты не должны иметь се- 
мантики значений — их нельзя копировать и присваивать как попало. 

Вот здесь-то и нужны интеллектуальные указатели. Большинство интеллектуаль- 
ных указателей, помимо имитации простых указателей, управляют владением объекта- 
ми, на которые они ссылаются. Они распознают изменения в правах владения, а их 
деструкторы освобождают память, следуя тщательно продуманной стратегии. Во 
многих интеллектуальных указателях содержится достаточно информации, чтобы пра- 
вильно освободить память, занятую объектом, на который они ссылаются. 

Управление владением осуществляется разными способами в зависимости от ре- 
шаемой задачи. Некоторые интеллектуальные указатели автоматически передают пра- 
ва на владение объектом: после копирования исходному указателю присваивается ну- 
левой адрес, а результирующему — адрес объекта и права на владение. Именно такая 
стратегия реализована в стандартном интеллектуальном указателе 514: : аито_ртг. 
Другие интеллектуальные указатели используют Подсчет ссылок: они отслеживают 
общее количество интеллектуальных указателей, ссылающихся на один и тот же объ- 
ект, и, когда счетчик обнуляется, удаляют его. В заключение заметим, что существуют 
интеллектуальные указатели, при копировании которых создается дубликат объекта. 

Владение объектом — важное свойство интеллектуальных указателей. Управляя 
правами владения, интеллектуальные указатели гарантируют целостность и полноцен- 
ную семантику значений. Поскольку права владения связаны в основном с созданием, 
копированием и уничтожением интеллектуальных указателей, соответствующие 
функции-члены наиболее важны. 

В следующих разделах мы рассмотрим разные аспекты разработки и реализации 
интеллектуальных указателей. Нашей целью будет максимально полная имитация 
простых указателей, но не будем забывать, что интеллектуальный указатель — более 
щирокое понятие. 

Между интеллектуальными и обычными указателями существует тонкая грань, от- 
деляющая полный контроль от хаоса. Мы увидим, что добавление на первый взгляд 
полезных свойств иногда оказывается весьма опасным. При реализации хороших ин- 
теллектуальных указателей следует соблюдать точный баланс. 
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7.3. Хранение интеллектуальных указателей 


Для начала зададимся фундаментальным вопросом: “Должна ли переменная ро1птее_ 
иметь тип т*?”. Если нет, то какой тип она может иметь? В обобщенном программирова- 
нии обязательно нужно задавать себе такие вопросы. Каждый тип, встроенный в обоб- 
щенный код, снижает степень его универсальности. Такие типы напоминают константы, 
“зашитые” в тексте программы. 

В некоторых ситуациях имеет смысл разрешить настройку типа переменной 
роїпсее . Например, это стоит сделать при работе с нестандартными модификатора- 
ми указателя. Во времена 16-битовых процессоров ие! 80х86 указатели могли иметь 
спецификаторь _пеаг, _Ғаг“ и _Ииде. Такие модификаторы могут использоваться и в 
других моделях сегментированной памяти. 

Вторая ситуация, в которой следует настраивать тип, возникает, когда программист 
хочет применить наследование интеллектуальных указателей. Что если У нас есть 
класс і едасуѕтагіріг<т>, реализованный кем-то еще, и нам нужно создать произ- 
водный от него класс? Как это сделать? Это ответственное решение. Лучше скрыть 
базовый класс внутри своего собственного интеллектуального указателя. Это вполне 
возможно, поскольку внутренний интеллектуальный указатель имеет ту же синтакси- 
ческую структуру. С точки зрения внешнего интеллектуального указателя переменная 
роїпсее имеет тип і едасуѕтагїРіг<Т>, а не Т“. 

Наследование интеллектуальных указателей обладает интересными приложениями, 
в основном благодаря оператору ->. Когда оператор -> применяется к типу, который 
отличается от встроенного, компилятор ведет себя необычно. После применения опе- 
ратора ->, определенного пользователем, к данному типу он вновь применяет опера- 
тор -> к полученному результату и продолжает рекурсивно повторять этот процесс, 
пока не обнаружит указатель на встроенный тип и только тогда предоставит доступ к 
члену класса. Следовательно, оператор ->, определенный в интеллектуальном указате- 
ле, не обязан возвращать указатель. Он может возвращать объект, который в свою 
очередь реализует оператор ->, не изменяя синтаксис его применения. 

Это приводит к интересной идиоме: вызовам пре- и постфункций (Ѕігоиѕігир, 
2000). Если оператор -> возвращает объект типа РОіЇпСегТуре по значению, последо- 
вательность его выполнения такова. 


1. Вызывается конструктор класса РоіпсегТуре. 


2. Вызывается функция Ро1птегтуре: : орегафог->; вероятно, возвращается указа- 
тель на объект типа Ро1птхеетуре. 


3. Доступ к члену класса Роіпсеетуре — вероятно, вызов функции. 
4. Вызывается деструктор класса РОЇ псегтТуре. 


Короче говоря, у нас есть превосходный способ блокировки вызовов функций. Эта идиома 
широко применяется в многопоточных средах для блокировки доступа к ресурсам. Конст- 
руктор класса РоїпісегТуре может захватывать ресурсы, мы их можем использовать в своих 
целях, а в конце работы деструктор класса РоіпёегТуре освобождает их. 

На этом обобщения не заканчиваются. Синтаксически-ориентированная часть 
“указателя” выглядит довольно бледно по сравнению с мощными средствами управ- 
ления ресурсами, которыми обладают интеллектуальные указатели. Следовательно, 
иногда интеллектуальные указатели могут вести себя подобно обычным. Объект, для 
которого не определены операторы -> и *, не соответствует определению интеллекту- 
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ального указателя. Однако существуют объекты, которые можно считать интеллекту- 
альными указателями, даже если они таковыми формально не являются. 

Вернемся в реальный мир прикладного программирования и приложений. Многие 
операционные системы реализуют дескрипторы (Нап ез) в виде методов доступа к оп- 
ределенным внутренним ресурсам, таким как окна, мьютексы или устройства. Деск- 
рипторы являются преднамеренно замаскированными указателями. Одно из их пред- 
назначений — предотвращать непосредственный доступ пользователей к критически 
важным ресурсам операционной системы. В большинстве случаев дескрипторы пред- 
ставляют собой целые числа, указывающие на скрытую таблицу указателей. Эта таб- 
лица обеспечивает дополнительный уровень защиты внутренней системы от приклад- 
ных программистов. Хотя для дескрипторов не предусмотрен оператор ->, по семан- 
тике и способу работы они похожи на указатели. 

Для дескрипторов нет смысла предусматривать оператор -> или *. Однако они предос- 
тавляют те же средства управления ресурсами, что и интеллектуальные указатели. 

Рассмотрим три типа интеллектуальных указателей. 


1. Тип хранения (5огаре іуре). Это — тип переменной ро1птее_. По умолчанию в 
обычных интеллектуальных указателях этот тип относится к обычным указателям. 


2. Тип указателя (роіпіег Туре). Это тип объекта, возвращаемого оператором ->. Он 
может отличаться от типа хранения, если хранится объект-заместитель (ргоху 
обіесі), а не сам указатель. (Позднее в этой главе мы рассмотрим пример объек- 
та-заместителя.) 


3. Ссылочный тип (те{егепсе їуре). Это тип, возврашаемый оператором *. 


В заключение заметим, что интеллектуальные указатели могут и должны обобщать 
все три перечисленных типа. Для этого класс $тагЕРЕг абстрагируєт их в стратегии 
Ѕтогаде. Конкретизация класса Ѕтагтріг не обязана реализовывать их все одновре- 
менно. Следовательно, иногда (например, в дескрипторах), стратегия может не опре- 
делять один из операторов -> и *, либо игнорировать их обоих. 


7.4. Функции-члены интеллектуальных указателей 


Многие существующие реализации интеллектуальных указателей допускают вы- 
полнение операций с помощью функций-членов, например, бет для доступа к объек- 
ту, Ѕеї — для его изменения и Ве1еаѕе — для отказа от владения. Вполне естествен- 
но инкапсулировать эти функциональные возможности в классе зтагтРТг. 

Однако опыт показывает, что функции-члены не очень удобны для реализации 
интеллектуальных указателей, поскольку взаимодействие между этими функциями 
крайне запутанно. 

Допустим, что у нас есть класс Ргіпсег с функциями-членами Асаи1ге и ке1еаѕе. 
С помощью функции-члена Асдиіге мы получаем права владения принтером, так что 
никакое другое приложение ничего напечатать не сможет, а с помошью функции- 
члена ве1еаѕе мы освобождаєм принтер. Используя интеллектуальный указатель на 
объект класса Ргіпсег, мы обнаруживаем его странную синтаксическую схожесть с 
конструкциями, имеющими совершенно иную семантику. 

зтагЕРЕГ<РГТИТег> 5рВе5 = ...; 


зрве$->Асаитге(); // вступаем по владение принтером 
... Печатаем документ ... 
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ЅрАеѕ->Ве1еаѕе(); // Освобождаєм принтер 

ѕркеѕ.ве1еаѕе(); // Освобождаєм указатель на принтер 
Пользователь класса ѕтагїіріг теперь имеет доступ к двум совершенно разным мно- 
жествам функций: функциям-членам объекта, на который ссылается интеллектуаль- 
ный указатель, и функциям-членам самого интеллектуального указателя. Выбор этих 
функций зависит от используемого оператора: точки или стрелки. 

Программисты на языке С++ вынуждены внимательно следить за тем, какой из 
операторов должен применяться в той или иной ситуации. Программисты на языке 
Разса|, изучающие язык С++, могут даже почувствовать отвращение к необходимости 
улавливать различия между операциями & и &&. Однако программисты на языке С++ 
не имеют права закрывать на это глаза. Они должны выработать в себе привычку лег- 
ко обнаруживать такие синтаксические различия. 

Привыкнуть к функциям-членам интеллектуальных указателей нелегко. Простые ука- 
затели не имеют функций-членов, поэтому операторы . и -> к ним не применяются. В 
этих ситуациях большую помошь оказывает компилятор: если программист поставил после 
обычного указателя точку, выдается сообщение об ошибке. Теперь легко себе представить, 
как разочарованы даже опытные программисты на языке С++ тем фактом, что компиля- 
тор допускает использование выражений ѕр.Ке1еаѕе() и зр->ве]еазе(), имеющих со- 
вершенно разный смысл. Избежать этого легко: интеллектуальный указатель не должен 
иметь функций-членов. Класс ѕмагтрте использует вместо них дружественные функции. 

Перегруженные функции также могут привести к недоразумениям, но ситуация здесь 
совершенно иная. В языке С++ перегруженные функции применяются довольно широко. 
Перегрузка является важной частью языка и часто применяется в библиотеках и приложе- 
ниях. Это значит, что программисты на языке С++ привыкли дифференцировать разные 
синтаксические формы вызова, например, ВеТеа5е("5р) и ВеЛеаѕе(ѕр). 

Функциями-членами класса ѕтагїрїг могут быть лишь конструкторы, деструктор, 
оператор =, оператор -> и унарный оператор *. Остальные операции, выполняемые 
классом 5тагтРтг, реализуются с помощью внешних функций. 

Для простоты класс ЗтагтРтг не использует именованные функции-члены. Един- 
ственными функциями, имеющими доступ к объекту, на который ссылается интел- 
лектуальный указатель, являются сесітрі, сетттр1 ве, кеѕет и ке1еаѕе, определен- 
ные в пространстве имен. І 

тетр1ате <с1аѕ5 т> Т* сесттр1 СЅтагїрРег<Тт>& 5р) ; 

тетр1ате <с1аѕ5 т> Т*& Сетітр1ке#(ѕтагтРїе<т>& зр); 


тетрТаге <с1аѕѕ т> моїа Веѕет (ѕпагтРег<т>& 5р, т* зоигсе); 
тетр1ате <с1аѕ5 т> моіа Ке1еаѕе(ѕЅтагтрег<т>& зр, Т*& деѕтіпатіоп) ; 


® Функция Сеїїтр1 возвращает указатель на объект, хранящийся в классе 
5тагЕРТГ. 


• Функция Сестітрівеї возвращает ссылку на указатель, хранящийся в классе 
Ѕтагіріг. Она позволяет изменять этот указатель, поэтому требует особой ос- 
торожности. : 


® Функция Везет возвращает указатель на другое значение, освобождая предыдущее. 


» Функция ве]еазе освобождает интеллектуальный указатель, возлагая на поль- 
зователя ответственность за управление объектом, на который он ссылался. 


Реальные объявления этих функций в библиотеке Г.оК1 немного сложнее. В них не 
предполагается, что указатель, хранящийся в классе $тагуРртг, имеет тип т*. Как ука- 
зано в разделе 7.3, тип указателя определяется стратегией Ѕїогаде. 


184 Часть ЇЇ. Компоненты 


7.5. Стратегии владения 


Владение объектом является смыслом существования интеллектуальных указате- 
лей. Они сами выполняют уничтожение объектов, на которые ссылаются. В то же 
время пользователь может влиять на продолжительность жизни объекта, вызывая 
вспомогательные функции. 

Для реализации прав владения интеллектуальный указатель должен внимательно 
следить за объектом, особенно во время копирования, присваивания и уничтожения. 
Это приводит к дополнительным затратам памяти и времени. Приложение должно 
определять стратегию, которая одновременно была бы удобной и эффективной. 

В следующих подразделах обсуждаются наиболее распространенные стратегии вла- 
дения и их реализации в классе ЅмагїрР?г. 


7.5.1. Глубокое копирование 


При копировании интеллектуального указателя простейшая стратегия заключается 
в копировании объекта, на который он ссылается. При этом на каждый объект будет 
ссылаться только один указатель. Следовательно, деструктор интеллектуального указа- 
теля может безопасно уничтожить такой объект. На рис. 7.1 проиллюстрирована схема 
распределения памяти для интеллектуальных указателей при глубоком копировании. 


ПР 


Рис. 7.1. Схема распределения памяти для интеллектуальных указателей при глубоком 
копировании 


На первый взгляд стратегия глубокого копирования выглядит бессмысленной. Ка- 
жется, что в этом случае интеллектуальные указатели нисколько не расширяют обыч- 
ную семантику значений языка С++. Зачем же их применять, если объект, на кото- 
рый они ссылаются, можно просто передавать по значению? 

Ответ заключается в поддержке полиморфизма. Интеллектуальные указатели пред- 
ставляют собой средство для безопасной передачи полиморфных объектов. Интеллек- 
туальньй указатель на базовый класс может ссылаться и на производные классы. При 
копировании интеллектуального указателя требуется копировать и его полиморфное 
поведение. При этом ни его поведение, ни состояние точно не известны. 

Поскольку глубокое копирование чаще всего применяется для полиморфных объ- 
ектов, приведенная ниже наивная реализация оказывается неверной. 


хетріасе <с1аѕ5 т> 
с1аѕ5 ЅмагірЕг 
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{ 
руБ11с: 
ЅтагірРіг(сопѕї Ѕтагірігё& оїтһег) 

: роіпсее (пем ТС®отћег.роіптее_)) 


} 


}; 
Допустим, что мы копируем объект типа 5тагЕРЕГг«міддеє». Если интеллектуальный 
указатель обНег ссылается на экземпляр класса Ехтепаеаміадеї, производного от 
класса міддес, конструктор копирования скопирует только ту часть объекта 
Ехтелдеаміддет, которая унаследована им от класса міадет. Это явление известно 
как срезка (ѕ1ісіпр) — копируется только “срез” класса міддет, содержащийся в объек- 
те более широкого класса Ехсепаейфміддеє. Срезка чаще всего совершенно нежела- 
тельна. Очень жаль, что в языке С++ она возникает так легко — простой вызов по 
значению обрезает объекты без всякого предупреждения. 

В главе 8 обсуждается глубокое клонирование. Классическим способом получения 
полиморфного клона иерархии является определение виртуальной функции СТопе и 
ее реализация, как показано ниже. 


с1аѕѕ АБзтгаствазе 


мігтиа? ваѕе* С]опе() = 0; 


, 


сТа55 сопсгете : рибТіс дбѕтгасїіваѕе 


мігтиа?) Вазе* С]опе() 
{ 


гетиги пем СопсгесеС"єНі5); 


$; 

Реализация функции СТопе должна быть одинаковой во всех производных классах. 
Несмотря на такую повторяюшуюся структуру, автоматического способа определения 
функции-члена СТопе (кроме макросов) не существует. 

Обобщенный интеллектуальный указатель не знает точно имя функции клониро- 
вания: может быть, с1опе, а может — МаКеСору. Следовательно, наиболее гибким 
подходом является параметризация класса ЅтагїРіг с помощью соответствующей 
стратегии адресации клонирования. 


7.5.2. Копирование при записи 


Копирование при записи (сору оп мгіїїе — СОМ) — это способ оптимизации, по- 
зволяющий избежать необязательного копирования объекта. Идея этого метода за- 
ключается в том, чтобы клонировать объект лишь при первой попытке его модифика- 
ции, а до тех пор на него может ссылаться несколько указателей. 

Однако интеллектуальные указатели не очень подходят для реализации стратегии 
СОУУ, поскольку они не умеют различать вызовы константньх и неконстантных функций- 
членов объекта, на который они ссылаются. Рассмотрим следующий пример. 


тетрТасе <с1аѕѕ т> 
сТа55 ЅптағїРіг 
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{ 
риБ1їс: 
т* орегатог->() { гетигп роїіпсее ; ) 


с1аѕ5 Боб 


рчЬ1іс: 
моіа СопѕҒғип () сопѕт; 
\014 мопсопѕїғип() ; 


Ѕтагірїг<Еоо> 5р; 
5р->Сопѕїғип() ; // вызывает оператор ->, 

// а затем — функцию Сопѕ?Еип 
эр->мопсоп$Рип() // Вызывает оператор ->, 

// а затем — функцию МопСоп5 СЕП 


Для обеих функций вызывается один и тот же оператор ->. Следовательно, интеллек- 
туальный указатель не может решить, применять стратегию СОМУ или нет. Вызовы 
функций объекта иногда выходят за рамки возможностей интеллектуальных указате- 
лей (в разделе 7.11 поясняется, как ключевое слово сопѕї влияет на интеллектуальные 
указатели и объекты, на которые они ссылаются). 

В заключение отметим, что стратегия СОМ наиболее эффективна при оптимиза- 
ции полноценных классов. Интеллектуальные указатели находятся на слишком низ- 
ком уровне, чтобы применять к ним копирование при записи. Разумеется, они, в 
свою очередь, могут представлять собой хорошие строительные блоки для реализации 
стратегии СОМ в каком-нибудь другом классе. 


7.5.3. Подсчет ссылок 


Подсчет ссылок (геїегепсе соипііпр) — наиболее распространенная стратегия владения 
объектом, используемая интеллектуальными указателями. В рамках этой стратегии произ- 
водится подсчет интеллектуальных указателей, ссылающихся на один и тот же объект. 
Когда их количество становится равным нулю, объект уничтожается. Эта стратегия работа- 
ет очень хорошо, если не нарушаются несколько правил — например, на один и тот же 
объект не должны ссылаться и обычный, и интеллектуальный указатели. 

Подсчет ссылок должен распространяться только на интеллектуальные указатели. 
Это приводит к структуре, изображенной на рис. 7.2. Каждый интеллектуальный ука- 
затель, кроме самого объекта, хранит указатель на счетчик ссылок (переменную рве#- 
Соип*_ на рис. 7.2). Обычно это приводит к удвоению размера интеллектуального ука- 
зателя, что может оказаться нежелательным. 

Сушествует еще один вопрос, связанный с расходом ресурсов. Интеллектуальные 
указатели с подсчетом ссылок должны хранить в динамической памяти счетчик ссы- 
лок. Проблема заключается в том, что во многих реализациях механизм распределе- 
ния динамической памяти, предусмотренный по умолчанию, работает довольно мед- 
ленно и неэффективно использует память при выделении ее для небольших объектов 
(глава 4). (Очевидно, счетчик ссылок, обычно занимающий 4 байт, следует считать 
небольшим объектом.) Потеря скорости происходит из-за медленного алгоритма по- 
иска доступных участков памяти (сћипкѕ), а затраты памяти вызваны необходимостью 
хранить информацию о каждом таком участке. 
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Относительный перерасход памяти может частично компенсироваться совместным 
хранением указателя и счетчика ссылок, как показано на рис. 7.3. Структура, изобра- 
женная на рис. 7.3, позволяет сократить размер интеллектуального указателя до раз- 
мера обычного указателя, но за счет скорости доступа: объект, на который ссылается 
интеллектуальный указатель создает дополнительный уровень косвенной адресапии. 
Это довольно значительный недостаток, поскольку обычно интеллектуальные указате- 
ли используются несколько раз, а создаются и уничтожаются — лишь однажды. 


ою. 
рВеЮоит_ РА 


шою 
Гаки Р 


= Б 
рАеїСоиті Г 


Рис. 7.2. Три интеллектуальных указателя, ссылающихся 
на один и тот же объект 
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Рис. 7.3. Альтернативная структура указателей с подсчетом ссылок 


Эффективнее всего хранить счетчик ссылок в самом объекте, на который ссылает- 
ся интеллектуальный указатель, как показано на рис, 7.4. Таким образом, объект кла- 
са зтагеРтг будет иметь размер обычного указателя, и дополнительных затрат памяти 
не будет совсем. Этот прием называется внедренным подсчетом ссылок (іпігиѕіуе 
геѓегепсе соипИп?), поскольку счетчик ссылок “внедряется” в объект, хотя семантиче- 
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ски он относится к интеллектуальному указателю. Его название напоминает также об 
ахиллесовой пяте этого приема: для реализации такой стратегии нужно модифициро- 
вать класс, которому принадлежит объект. 


р 


=. 


геїСоцпі 23 
шою. 


Рис. 7.4. Внедренньй подсчет ссылок 


Обобщенньй интеллектуальный указатель должен при первой возможности ис- 
пользовать внедренный подсчет ссылок, а обычную схему подсчета ссылок следует 
рассматривать в качестве приемлемой альтернативы. Для реализации обычной схемы 
подсчета ссылок очень удобно применять механизм распределения памяти для не- 
больших объектов, описанный в главе 4. Он позволяет снижать дополнительные за- 
траты, вызванные необходимостью хранить счетчик ссылок. 


7.5.4. Связывание ссылок 


На самом деле нет никакой необходимости подсчитывать интеллектуальные указа- 
тели, ссылающиеся на один и тот же объект. Нужно лишь определять, когда этот 
счетчик станет равным нулю. Это приводит к идее “списка владельцев” (омпегѕћір 
1150), показанного на рис. 7.5,! и стратегии связывания ссылок. 

Все объекты класса этагтРтг, ссылающиеся на заданный объект, заносятся в два- 
жды связанный список. Новый объект класса ѕтагіРїг, создаваемый на основе суще- 
ствующего, добавляется в список, а деструктор этого класса удаляет уничтоженные 
объекты из списка. Когда список становится пустым, объект удаляется. 

Структура дважды связанного списка идеально подходит для отслеживания ссылок. 
Использовать односвязный список невозможно, поскольку удаление элемента из та- 
кого списка занимает линейное время. Вектор применить нельзя, так как объекты 
класса ѕтағгїРїг не занимают смежные участки памяти (и на удаление элементов из 
вектора также тратится линейное время). Нам нужна структура, в которой удаление и 
вставка элементов, а также проверка заполненности занимали бы одинаковое время. 
Единственной структурой, удовлетворяющей этим требованиям, является дважды свя- 
занный список. 

В реализации стратегии связывания ссылок в каждом объекте класса ѕптагїРЕг 
хранятся два дополнительных указателя — на следующий и на предыдущий элементы. 


1 Механизм связывания ссылок описан Ристо Ланкиненом (Візіо ГапКтеп) в форуме Оѕепег 
в ноябре 1995 года. 
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Рис. 7.5. Связывание ссылок 


Преимущество связывания ссылок перед их подсчетом проявляется в том, что при пер- 
вом способе не требуется дополнительная память. Это делает стратегию более надежной. 
Создание интеллектуального указателя со связыванием ссылок всегда работает безотказно. 
Недостатком этой стратегии является тот факт, что при связывании необходимо больше 
памяти для регистрации (три указателя вместо одного плюс одно целое число). Кроме то- 
го, подсчет ссылок выполняется немного быстрее — при копировании интеллектуального 
указателя необходима только одна косвенная адресация и одна операция инкрементации. 
Управление списком также немного сложнее. В заключение отметим, что связывание ссы- 
лок следует применять только при недостатке динамической памяти. В противном случае 
предпочтительнее использовать подсчет ссылок. Г 

Завершая обсуждение стратегий управления ссылками, обратим внимание на их 
существенный недостаток. Управление ссылками — с помощью подсчета или связы- 
вания — приводит к утечке ресурсов, так называемой циклической ссылке (сусіїс 
геїсгепсе). Представьте себе, что объект А содержит интеллектуальный указатель на 
объект в, и, наоборот, — в объекте в хранится интеллектуальный указатель на объект 
А. Эти два объекта образуют циклическую ссылку. Даже если вы не используете эти 
объекты, они сами друг друга используют. Стратегии управления ссылками не спо- 
собны распознавать такие ситуации, и эти два объекта останутся в динамической па- 
мяти навсегда. Циклы могут распространяться на несколько объектов, создавая между 
ними связи, которые очень трудно отследить. 

Несмотря на это, управление ссылками представляет собой надежную и быструю 
стратегию владения объектами. Если применять его с необходимыми предосторожно- 
стями, оно значительно облегчает разработку приложений. 


7.5.5. Разрушающее копирование 


Разрушающее копирование (еѕїгисііуе сору) — это именно то, о чем вы подумали: 
во время копирования оригинал уничтожается. Разрушающее копирование уничтожа- 
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ет оригинальный указатель, передавая объект, на который он ссылался, другому ин- 
теллектуальному указателю. В шаблонном классе $14: :айто рег применяется именно 
этот вид копирования. 

Опасность этой стратегии очевилна. Неправильное разрушающее копирование 
может уничтожить данные, программу и ващу репутацию программиста. 

Эту стратегию следует применять только в том случае, когда в каждый момент 
времени на данный объект ссылается только один интеллектуальный указатель. Во 
время копирования или присваивания одного интеллектуального указателя другому “в 
живых” остается только результирующий указатель, а оригинал обнуляется. Ниже по- 
казаны конструктор копирования и оператор присваивания простого класса ЗтагЕРЕг, 
демонстрирующие разрушающее копирование. 


хетрТасе <с1аѕѕ т> 
с1аѕ5 Ѕтагїріг 


риБ1їс: 
Ѕтагіріг(Ѕтагїріг& 5С) 


ро1птее_ = 5гс.роїпгее ; 
5гс.роїпсее = 0; 


ЅтагіРіг& орегатог= (ѕЅтагірег& $гс) 
ЗРО (ЕҺ15 |з &5гс) 
{ 


де1ете ро1птее_; 
роіпіее_ = 5сс.роїпіее,; 
5гс.ро1птее_ = 0; 

} 


гехигп *1Н1$; 


р: 

По правилам языка С++ в правой части конструктора копирования и оператора 
присваивания должна стоять ссылка на константный объект. Классы, реализующие 
разрушающее копирование, нарушают это правило по очевидным причинам. По- 
скольку правила языка основаны на резонных соображениях, от их нарушения нельзя 
ожидать ничего хорошего. Действительно, рассмотрим следующий пример. 


уоіа ріѕр1ау(ѕтагтрег<ѕотетћіпд> 5р); 


Ѕмагтріг<ѕотетһіпо> зр(пем 5отесНніпд); 

ріѕр1ау(5р); // Уничтожает объект 5р 
Несмотря на то что функция ріѕр1ау не представляет опасности для своего аргумента 
(принимая его по значению), она действует как водоворот: все интеллектуальные ука- 
затели, попавшие в нее, тонут безвозвратно. После вызова ріѕр1ау(5р) указатель ѕр 
хранит нулевой адрес. 

Поскольку интеллектуальные указатели, реализующие стратегию разрушающего копи- 
рования, не поддерживают семантику значений, их нельзя хранить в контейнерах и вооб- 
ще с ними нужно обращаться почти так же осторожно, как и с обычными указателями. 

Возможность хранить интеллектуальные указатели в контейнере чрезвычайно важ- 
на, поскольку контейнеры, состоящие из обычных указателей, очень усложняют руч- 
ное управление владением. Однако интеллектуальные указатели, реализующие стра- 
тегию разрушающего копирования, для этого не подходят. 
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С другой стороны, интеллектуальные указатели, реализующие стратегию разру- 
шающего копирования, имеют ряд преимуществ. 


• Они почти не тратят дополнительной памяти. 


• Они удобны для передачи владения другому указателю. В этом случае использу- 
ется “эффект водоворота”, описанный выше. 


• Они удобны в качестве возвращаемого функцией значения. Если в реализации 
интеллектуального указателя используется определенный трюк?, можно воз- 
врашать из функций интеллектуальные указатели с разрушающим копировани- 
ем. Таким образом, можно быть уверенным, что если в вызывающем модуле 
возвращаемое значение не используется, оно уничтожается. 


» Они превосходнь в качестве переменных стека в функциях, возврашаюших 
значения несколькими способами. Предпринимать меры для уничтожения объ- 
екта, на который ссылается интеллектуальный указатель, необязательно — он 
сам это сделает. 


Стратегия разрушающего копирования используется в стандартном классе 
5сд::айсо ріг. Это создает дополнительное преимущество. 


• Интеллектуальные указатели, обладающие семантикой разрушающего копиро- 
вания, являются единственным стандартом. Это значит, что многие программи- 
сты рано или поздно станут их использовать. 


По этим причинам реализация класса ЅтагтгрРег должна предусматривать дополни- 
тельную поддержку семантики разрушающего копирования. 

Интеллектуальные указатели используют разные стратегии владения, каждая из Ко- 
торых имеет свои достоинства и недостатки. К наиболее важным приемам относятся 
глубокое копирование, подсчет ссылок, связывание ссылок и разрушающее копирова- 
ние. Класс ЅтагїрР+г реализует все эти способы в виде стратегии Омпег5Нір, позволяя 
своим пользователям выбирать из них наиболее подходящий. По умолчанию предла- 
гается стратегия подсчета ссылок. 


7.6. Оператор взятия адреса 


Стремясь сделать интеллектуальные указатели максимально похожими на их обычные 
прототипы, разработчики натолкнулись на незаметный перегружаемый унарный оператор 
& или оператор взятия адреса (аддтез5-ої орегаќог)?. 

Программист, реализующий интеллектуальные указатели, может перегрузить этот 
оператор следующим образом. 


тетр1ате <с1аѕѕ т> 
с1аѕ5 ЅмагїрТг 


риБ1іс: 
Т** орегатог&С) 


гетиғп &роіптее_; 


2 Изобретенный Грегом Колвином (Стее Соіміп) и Биллом Гиббонсом (ВШ СіБЬопѕ) для 
стандартного интеллектуального указателя 514: : аито_ртг. 

З Унарный оператор & следует отличать от бинарного оператора &, представляющего собой 
побитовый оператор АМО. 
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фі 
Помимо всего прочего, если интеллектуальный указатель должен имитировать обыч- 
НЫЙ указатель, то его адрес можно заменять адресом обычного указателя. В этом слу- 
чае становится возможной следующая перегрузка оператора. 


моіа Ейп(міддестя риіадеї); 


Ѕмагїіртг<міадет> ѕриіадетс...); 
Рип (&ѕрмі адет) ; // Вызывает оператор * и получает указатель 
// на указатель на объект класса міддеї 

На первый взгляд было бы замечательно иметь полную совместимость интеллекту- 
альных и обычных указателей, однако перегрузка унарного оператора & относится к 
тем остроумным трюкам, которые приносят больше вреда, чем пользы. 

Есть две причины, по которым перегрузка унарного оператора & опасна. Первая заклю- 
чается в том, что явное определение адреса объекта, на который ссылается интеллектуаль- 
ный указатель, отнимает возможности автоматического управления владением. Если поль- 
зователь имеет свободный доступ к адресу указателя, любая вспомогательная структура, 
содержашаяся в интеллектуальном указателе, например, счетчик ссылок, становится нера- 
ботоспособной. Если пользователь непосредственно оперирует адресом обычного указате- 
ля, интеллектуальный указатель становится полностью неуправляемым. 

Вторая причина более прагматична. Дело в том, что перегрузка унарного оператора 
& делает невозможным использование интеллектуального указателя в сочетании с 
контейнерами из стандартной библиотеки шаблонов 511. Фактически перегрузка 
унарного оператора & не позволяет применять обобщенное программирование, по- 
скольку адрес любого объекта — слишком важное свойство, чтобы так просто с ним 
обращаться. В большинстве обобщенных кодов предполагается, что применение опе- 
ратора & к объекту типа Т возвращает объект типа Т*. Как видим, оператор взятия ад- 
реса представляет собой фундаментальное понятие обобщенного программирования. 
Если им пренебречь, обобщенный код будет вести себя странно как на этапе компи- 
ляции, так и (что намного хуже) во время выполнения программы. 

Таким образом, перегружать унарный оператор & для интеллектуальных указателей 
и вообще для любых объектов не рекомендуется, поэтому в классе ѕмагїріг унарный 
оператор & не перегружается. 


7.7. Неявное приведение ктипам обычных указателей 


Рассмотрим следующий код. , 
моїд ғип(ѕотетћіпд* р) 

Ѕтагерїіг (Ѕотетһіпод> ѕр (пем ѕотеїћіпд) ; 

ғип(ѕ=р); // Правильно или нет? 


Скомпилируется этот код или нет? По принципу “максимальной совместимости” 
правильный ответ — “да”. 

С технической точки зрения сделать приведенный выше код компилируемым очень 
легко. Для этого достаточно ввести преобразование, определенное пользователем, 


тетр1ате <с]а$$ т> 
с1аѕ55 ЅмагїРїг 
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риБ1їс: 
орегатог Т*() // Приведение к типу Т“, 
// определенное пользователем 
{ 


} 


}; 

Однако это еще не все. 

Преобразования типов, определенные пользователем, имеют весьма интересную 
историю. В 1980-х годах, когда они впервые появились в языке С++, большинство 
программистов считали их огромным достижением. Они позволяли разрабатывать 
единообразные системы типов, повышать выразительность семантики и определять 
новые типы, отличающиеся от встроенных. Однако впоследствии оказалось, что пре- 
образования типов, определенные пользователем, неудобны и потенциально опасны. 
Они могут стать опасными особенно при обработке внутренних данных (Меуегѕ, 
1998а, Пет 29). Именно это происходит с типом Т* в приведенном выше коде. Вот 
почему следует хорошенько подумать, прежде чем допускать автоматическое преобра- 
зование интеллектуальных указателей в вашей программе. 

Одна из потенциальных опасностей происходит от неконтролируемого доступа 
пользователя к обычному указателю, который скрыт внутри интеллектуального. Пере- 
дача обычного указателя во внешнюю среду нарушает внутреннюю работу интеллекту- 
ального указателя. Вырвавшись из своей оболочки, обычный указатель может легко 
стать угрозой для нормального функционирования программы, как это было до появ- 
ления интеллектуальных указателей. 

Другая опасность исходит от непредвиденного выполнения преобразований, опре- 
деленных пользователем, даже когда они совершенно не нужны. Рассмотрим следую- 
щий пример. 


гетигп роіптее_; 


ЅтагтРЕг<Ѕотеїһћіпа> зр; 


// Грубая семантическая ошибка. 

// Однако компилятор ее не распознает 

деТете зр; 

Компилятор сопоставляет оператор де1ете с преобразованием к типу Т*, определенным 
пользователем. Во время выполнения программы вызывается оператор Т*, и к результа- 
ту его работы применяется оператор 4е1ете. Очевидно, это совершенно не то, что тре- 
буется от интеллектуального указателя, поскольку предполагается, что он сам управляет 
правами владения. Лишний и непреднамеренный вызов оператора 4е1ете нарушает всю 
тщательно отлаженную систему управления правами владения, скрытую внутри интел- 
лектуального указателя. 

Есть несколько способов преодотвратить компиляцию вызова оператора де]ете. 
Некоторые из них очень остроумны (Меуегѕ, 1996). Эффективнее и удобнее всего сде- 
лать вызов оператора 4е1ете внутренне неоднозначным (ат виоцз). Этого можно дос- 
тичь, предусмотрев два приведения к типам, реагирующих на вызов оператора Яе]ете. 
Один из типов — это сам тип Т*, а вторым может быть тип моїа“. 


тетр1ате <с1аѕ5 т> 
с1аѕѕ ЅмагїРїіг 


риБ11с: 


орегатог Т*() // Приведение к типу ТУ, 
// определенное пользователем 
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{ 
} 


"орегасог \014*() // добавляется приведение к типу усій? 


гетигп роїїптгеєе ; 


гетигп роїптее ; 


}; 
Применение оператора де1ете к интеллектуальному указателю неоднозначно. Ком- 
пилятор не сможет решить, какое из преобразований следует выполнить. Именно 
этого мы и добивались. | 

Не забывайте, что блокировка оператора деїете — это только часть проблемы. Остает- 
ся решить, применять ли автоматическое преобразование интеллектуального указателя в 
простой указатель. Разрешить — слишком опасно, запретить — очень легко. Окончатель- 
ная реализация класса $тагРЕг предоставляет программисту право выбора. 

Однако запрет неявного преобразования не означает полного исключения доступа 
к обычному указателю. Иногда такой доступ просто необходим. Следовательно, все 
интеллектуальные указатели должны обеспечивать явный доступ к скрытому внутри 
них обычному указателю с помощью вызова функции. 

уоїд ғип(ЅѕЅометћіпд* р) 


зтагеРТг<5отетНн1па> зр; 

Еип(Ссетттр1 ($р)); // явное преобразование всегда разрешено 

Вопрос заключается не в том, можете ли вы получить доступ к обычному указате- 
лю, а В том, насколько это легко. Может показаться, что разница между явным и не- 
явным преобразованиями невелика, однако она очень важна. Неявное преобразование 
происходит независимо от программиста, он может даже ничего не знать о нем. Яв- 
ное преобразование, как, например, вызов функции Сесїтр1, выполняется осознанно, 
управляется программистом и не скрывается от пользователей программы. 

Неявное преобразование интеллектуального указателя в простой указатель жела- 
тельно, но иногда опасно. Класс ЅмагїРТг предоставляет программисту право самому 
решать, допускать его или нет. По умолчанию предлагается безопасный вариант — 
неявное преобразование запрещается. Явный доступ к обычному указателю всегда от- 
крыт через функцию бетттр1. 


7.8. Равенство и неравенство 


Любой трюк в языке С++, например, описанный выше (внутренняя неоднознач- 
ность), создает новый контекст, который в свою очередь может иметь неожиданные 
последствия. 

Рассмотрим проверку интеллектуальных указателей на равенство и неравенство. 
Интеллектуальный указатель должен поддерживать такой же синтаксис проверки, что 
и обычные указатели. Программист ожидает, что приведенные ниже проверки будут 
скомпилированы и выполнены. 

зтагЕРТГг<Зотетн1п9> $р1, 5р2; 

Ѕотеєһћіпд* р; 


1Ё Сѕр1) // проверка 1: прямая проверка ненулевого указателя 
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1+ (15р1) // проверка 2: прямая проверка нулевого указателя 
б (5р1 == 0) // проверка 3: явная проверка нулевого указателя 
1 (5р1 == 5р2) // проверка 4: сравнение двух интеллектуальных указателей 


1 (5р1 == р) // Проверка 5: сравнение с обычным указателем 
В этом фрагменте проиллюстрировань не все возможные проверки. Реализовав про- 
верку равенства, мы сможем легко проверять и неравенства. 

К сожалению, между проблемой проверки равенства и проблемой предотвращения 
компиляции оператора аӢеЛете существует скрытая связь. Если в программе определе- 
но только одно преобразование, болынинство проверок (за исключением проверки 4) 
проходит успешно, и программа выполняется в соответствии с ожиданиями програм- 
миста. Единственный недостаток — возможность непредвиденного применения опе- 
ратора деТесе к интеллектуальному указателю. Если в программе определены два 
преобразования (внутренняя неоднозначность), неверные вызовы оператора аеТете 
распознаются, но ни одна из указанных выше проверок больше не компилируется — 
они также становятся неоднозначными. 

Дополнительное преобразование интеллектуального указателя в булевскую пере- 
менную является полезным, но небезопасным. Рассмотрим следующее определение 
интеллектуального указателя. 


тетр1ате <с1аѕѕ т> 
с1аѕ5 ЅтагЕрїг 


{ 
рир1їс: 
орегатог Боо1() сопѕт 


гетигп роіпіее_ ! = 0; 


Б 
Четьре указанные выше проверки успешно компилируются, но при этом выполняют- 
ся следующие бессмысленные операции. 


зтагЕРЕГ<Арр1е»з 5р1; 
ЅтагіРтг<Огапде> 5р2; // яблоко и апельсин — не одно и то же 
1+ (5р1 == 5р2) // оба указателя преобразовываются 

// в булевскую переменную, 

// а результаты сравниваются 


ЛЕ (5р1 Із 5р2) // То же самое 
роої Б = $р1; // допустимая операция 
1 (5р1 * 5 == 200) // ой! интеллектуальный указатель 


// ведет себя как целое число! 

Как видим, мы можем получить либо все, либо ничего. Добавив преобразование 
интеллектуального указателя в булевскую переменную, мы допустили ситуации, когда 
объект класса ѕтагтрРтг ведет себя неправильно. Таким образом, определение опера- 
тора 6001 для интеллектуального указателя оказалось неразумным решением. 
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Истинное, всеобъемлющее и надежное решение этой дилеммы заключается в полной 
перегрузке всех операторов по отдельности. При таком подходе все операции, имеющие 
смысл для обычных указателей, окажутся применимыми и для интеллектуальных указате- 
лей без каких-либо побочных эффектов. Вот как можно реализовать эту идею. 


хетрТате <с1а$$ т> 
с1аѕѕ 5тагиЕРІГ 


рчБ11с: 
роо1 орегатог! () сопѕт // Допускает оператор "її С!$р) 


гетигп роїптеєе = 0; 


іпіїпе Ёгіепа Боо] ореғатоғ== Ссопѕт Ѕтагїіртг& 11$, 
сопѕ1 т* гһѕ) 
{ 


гетигп 1һѕ.роіптее_ == гИ$; 


1п1іпе Ғгіепа Боо1 орегатог==Ссопѕє т* 1һѕ, 
соп5С Ѕмагтріг* гНі5) 


гетигп 11$ == бһѕ.роіптее_; 


іп1іле Ғеіепа Боо] орегатог!=(соп$Е ЅмагіРігё 1һѕ, 
соп5С т* гһѕ) 


гесигп 1ћ5.роіптее_ != гһѕ; 


іп1іпе Ёгіепа Боо1 орегатог!=(сопѕ_ т* 1һѕ, 
сопѕ1і ЅтагїірРЕг& гһѕ) 


гетигп 1һ5 != кһѕ, роіптее_; 


У; ( 

Да, это неприятно, однако этот подход решает проблемы, касающиеся практически 
всех сравнений, включая сравнение с литеральным нулем. Операторы пересылки, со- 
держащиеся в этом фрагменте кода, перелают операторы, которые код пользователя 
применяет к интеллектуальным указателям, обычным указателям, скрытым внутри. 
Это самое реалистичное решение. 

Однако проблема решена не полностью. Если в программе предусматривается ав- 
томатическое преобразование указателей, остается риск, связанный с неоднозначно- 
стью такой операции. Допустим, у нас есть класс Ваѕе и класс регіуей, производный 
от него. Тогда в следующем коде будет содержаться неоднозначность. 


Ѕтагтрїг<Ваѕе> зр; 
регімеа* ‘р; 


1Ғ (зр == р) Є // Ошибка! Существует неоднозначность между 
. // проверкой ' (Ваѕе*)ѕр == (Ваѕе*)р' и 
// функцией 'орегатог==(5р, (Ваѕе*)р)' 
Действительно, разработка интеллектуальных указателей — занятие не для слабонервных. 
Но и это еще не все. Кроме определения операторов == и ! =, мы можем создать их 
шаблонные версии. 


тетр1ате <с1а$$ т> 
сТа55 ЅтагірЕг 
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1 
риб11с: 
100... как и раньше ... 
тетр1ате <с1аѕ55 Ц» 
іпііпе Ғгіепа боої орегатог== (сопѕє ѕтаг_Ріг& 1һ5, 
соп5с 05 гі5) 
1 


) 

тетр\1ате «сТає5 0» 

зпЛіпе Ёгіепа Боо] орегатог==(соп$® ця 11$, 
сопѕї Ѕмагтртіг& гі5) 


геёигп Ти5.роїптев == гИ$; 


гесигп 15 == гИ$.ротптее_; 


} 


... аналогично определенный оператор != ... 

$; 

Шаблонные операторы выполняют сравнения с любым типом указателей, устраняя 
неоднозначность. 

Если все так хорошо, зачем сохранять обычные, не шаблонные операторы, рабо- 
тающие с типами объектов, на которые ссылаются указатели? Эти операторы никогда 
не пройдут процедуру сопоставления, потому что шаблоны сопоставляют любые типы 
указателей, в том числе и типы объектов, на которые ссылаются указатели. 

Однако “никогда не говори никогда”. При выполнении проверки її (5р == 0) 
компилятор пытается выполнить следующие сопоставления. 


• Шаблонные операторы (етрыеЯ орегаїогѕ). Они не проходят проверку, по- 
скольку нуль не является типом указателей. Литеральный нуль можно неявно 
преобразовать в тип указателей, однако шаблонное сопоставление не преду- 
сматривает преобразований типов. 


‚ Нешаблоннье операторы (попіетріаїеа орегаѓогѕ). Исключив щаблонные опера- 
торь, компилятор переходит к проверке нешаблонных. Один из этих операто- 
ров оказывается подходящим после выполнения неявного преобразования ли- 
терального нуля в тип указателя. Если бы нешаблонных операторов не было, 
проверка завершилась бы сообщением об ошибке. 


Итак, и шаблонные, и нешаблонные операторы одинаково необходимы. | 
Посмотрим теперь, что произойдет при попытке сравнения двух классов ЗтагЕРХг, 
конкретизированных разными типами. 


ЅтагтрРег<Арр1е> $р1; 
бтмагсРЕг«Огапде» 5р2; 
1Р (5рі == 5р2) 


Компилятор споткнется на этом сравнении из-за неоднозначности: в каждой из этих двух 
конкретизаций определен оператор ==, и компилятор не знает, который из них выбрать. 
Мы можем избежать этой проблемы, определив “ликвидатор неоднозначностей”. 


тетр1ате «сТа55 т> 

сТа55 5тагоРЕГ 

{ 

риБ1іс: 
// Ликвидатор неоднозначностей 
тетр1ате <с1аѕѕ5 Ц» 
бос! орегатог==(сопѕї Ѕтагтртг<0и>& гН$) сопѕт 
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гетигп роїпсее == гл5.роїпсеєе ; 
// Адналогично для оператора != 


гт 


Новый оператор является членом класса, предназначенным исключительно для 
сравнения объектов классов ЅтагіРіг<...>. Прелесть этого ликвидатора неоднознач- 
ностей заключается в том, что он сравнивает интеллектуальные указатели, как обыч- 
ные указатели. Если сравнить два интеллектуальных указателя на объекты классов Ар- 
рТе и Огапде, код будет, по существу, эквивалентным сравнению обычных указателей 
на классы Арр1е и Огапде. Если это сравнение имеет смысл, код компилируется, в 
противном случае выдается сообщение об ошибке. 

5тпагсРСг«АррТіе» $р1; 

ЅпагіРіг<Огапде> 5р2; 

і? (5рі == 5р2) // Семантически эквивалентно сравнению 

// 5р1.роіпсее_ == 5р2.роїіпїее_ 

Остался один неприятный артефакт — непосредственная проверка її (зр). Вот 
это уже действительно интересно! Оператор 1+ применяется только к выражениям 
арифметического типа или к указателям. Следовательно, чтобы скомпилировать опе- 
ратор її? (С5р), нужно определить автоматическое преобразование интеллектуального 
указателя в арифметический тип или в обычный указатель. 

Преобразовывать интеллектуальный указатель в арифметический тип не рекомендуется 
по тем же причинам, которые были указаны при преобразовании в булевский тип. Указа- 
тель — это не арифметический тип, и точка! Преобразование интеллектуального указателя 
в обычный имеет больше смысла, но туг возникают новые проблемы. | 

Если нужно преобразовать интеллектуальный указатель в тип, на который он ссы- 
лается (см. предыдущий раздел), у нас есть выбор: либо рисковать, допуская возмож- 
ность непредвиденного вызова оператора ае]ете, или воздержаться от проверки 
1 (зр). Что выбрать: неудобство или опасность? Следует предпочесть безопасность, 
поэтому проверку 1Ё (5р) выполнять не следует. Вместо этого можно выбрать про- 
верку 1Ё(5р !- 0) или более вычурное выражение 1ЁС!! 5р). 

Если вы не хотите предусматривать преобразование интеллектуального указателя в тип, 
на который он ссылается, можно прибегнуть к интересному трюку, который позволит все 
же выполнить проверку 1Ё (5р). Внутри шаблонного класса зтагЕРег нужно определить 
внутренний класс Тезтег и преобразование в тип Тезтег*, как показано ниже. 


ТетрТате <с1аѕ5 т> 
сТа55 зтагеРЕг 


с1аѕ5 Теѕтег 
уоіа орегатог аде1есе(моіа*) ; 


р 
рибтіс: 
орегатог Тезтег*() соп5ї 
Р (!роіпсее_) гетигп 0; 


ѕЅтатіс Тезтег тезт; 
гетигп без; 
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Теперь при компиляции оператора ії (зр) в действие вступит оператор Тезтег*. 
Этот оператор возвращает нулевое значение тогда и только тогда, когда переменная 
ро1птее_ равна нулю. Класс Тезтег блокирует оператор 4еТете, поэтому, если ка- 
кой-нибудь код вызовет оператор ӣе1ете 5р, возникнет ошибка компиляции. Обрати- 
те внимание на то, что определение самого класса Тезтег находится в закрытом раз- 
деле класса $тагЕРтг, поэтому клиентский код ничего не знает о нем. 

Класс ЗтагеРтг решает проблемы, связанные с проверкой равенства и неравенст- 
ва, следующим образом. 


® Определяются операторы == и != двух видов (шаблонные или нешаблонные). 
» Определяется оператор !. 


« Если допускается автоматическое преобразование интеллектуального указателя в 
тип, на который он ссылается, то определяется дополнительное преобразование в 
тип моїй“, преднамеренно создающее неоднозначность при вызове оператора де- 
Лете. В противном случае определяется внутренний класс Тезтег, объявляющий 
закрытый оператор аеЛете и определяющий преобразование класса ѕтагіРЕг в тип 
тезтег*, возврашающее нулевой указатель тогда и только тогда, когда объект, на 
который ссылается интеллектуальный указатель, является нулевым. 


7.9. Отношения порядка 


К операторам отношения порядка относятся операторы <, <=, > и >=. Все эти опе- 
раторы можно свести к одному оператору <. 

Допускать ли упорядоченность интеллектуальных указателей — вопрос интересный сам 
по себе. Он основан на двойственной природе указателей, которая часто смущает про- 
граммистов. Указатели одновременно являются итераторами и моникерами (топ егэ). Бу- 
дучи итераторами, указатели могут перемещаться по массиву объектов. Арифметика указа- 
телей, включая операции сравнения, поддерживает их итеративную природу. В то же вре- 
мя указатели являются моникерами -- удобным способом быстрого доступа к объектам. 
Эту ипостась указателей обеспечивают операторы разыменования * и ->. 

Двойственная природа указателей иногда может приводить в замешательство, осо- 
бенно когда указатель нужно использовать только в одном качестве. Для работы с 
векторами может понадобиться как перемешение по массиву, так и разыменование, в 
то время как перемещение по связанному списку или манипуляция индивидуальными 
объектами используют только операцию разыменования. 

Отношения порядка между указателями определены только для указателей, при- 
надлежащих непрерывному участку памяти. Иными словами, сравнивать между собой 
можно лишь те указатели. которые ссылаются на элементы одного и того же массива. 

Определение отношений порядка для интеллектуальных указателей порождает во- 
прос: могут ли интеллектуальные указатели ссылаться на объекты, хранящиеся в од- 
ном и том же массиве? На первый взгляд нет. Основное свойство интеллектуальных 
указателей заключается в том, что они управляют правами владения объектами, а объ- 
екты с разными правами владения не могут принадлежать одному и тому же массиву. 
Следовательно, было бы рискованно выполнять бессмысленные сравнения. 

Если отношения порядка действительно необходимы, всегда можно применить яв- 
ный доступ к обычному указателю, хранящемуся внутри интеллектуального. Здесь 
снова нужно искать наиболее безопасный и выразительный способ сравнения. 

В предыдущем разделе мы пришли к выводу, что неявное преобразование интел- 
лектуального указателя в обычный — вопрос выбора. Если пользователь класса 
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стагЕРхг позволяет неявное преобразование, то приведенный ниже код будет успеш- 
но скомпилирован. 
зтагсРЕГ«5отетНіпд» $р1, 5р2; 


ЇР ($р1 < 5р2) // превращаем интеллектуальные указатели 
// 5р1 и 5р2 в обычные, а затем сравниваем их 


Это значит, что блокировать отношения порядка следует явно. Для этого достаточно 
объявить их, но не определять. При попытке выполнить такую проверку во время ре- 
дактирования связей возникнет ошибка. 

тетр1ате <с1аѕѕ т> 

с1аѕ5 стагтРТг 


Роа 


тетр1атсе <с1аѕ5 Т, сТа55 Ц» 

роо1 орегатог<Ссопѕї ѕтагтрРіг<Т>&, сопѕт и&):; // Не определен 

хетрТасе <с1аѕѕ т, с1аѕѕ у> 

роо1 орегатог<Ссопѕї Те, соп5с ЅтагіРТг<0у>&) ; // Не определен 

Благоразумнее выразить остальные операторы через оператор <, оставив его неоп- 
ределенным. Таким образом, если пользователь класса ѕтагїрРтг все же захочет уста- 
новить между его объектами отношение порядка, ему останется лишь определить со- 
ответствующий оператор <. 

// ликвидатор неоднозначностей 


хетрТасе <с1аѕѕ Т, с1аѕѕ у» 
роо! орегатог< Ссопѕї $тагЕРтг<Т>& 11$, сопзф ЗтагЕРтг<у>& гИ$) 


гехигп 16$ < Сесітрі(гі5); 


// все остальные операторы 

тетр1ате <с1аѕ5 т, с1а$$ Ц» 

ђоо1 орегатог> (бтагтРТг<Т>& 1И$, сопѕі и& гһѕ) 

{ і 


гетиги гНз < 11$; 


... аналогично для остальных операторов 


Обратите внимание на ликвидатор неоднозначностей. Теперь, если какой-нибудь 
пользователь библиотеки полагает, что объекты класса зтагтРтг<и1адет> должны 
быть упорядочены, он может написать следующий код. 


іп1іпе 6001 орегатог<(соп${ зтагертг<и1адет>& 115, 
соп5 С м14дет* гһѕ) 


гетигп бетттр1 (18$) < гһѕ; 
} 


іп\ііпе Боо] орегатог<(сопѕт міадет* 11$, 
сопѕї ЅмагїРтге<и1адес>& гһѕ) 


гетиги 11$ < СетІмр1Сеһѕ); 


Жаль, что пользователь должен определять два оператора, а не один, но это все же 
лучше, чем если бы он определял все восемь операторов. 

На этом обсуждение отношения порядка между интеллектуальными указателями 
можно было бы закончить. Ничего интересного в этой проблеме обнаружить не уда- 
лось. Иногда очень полезно установить отношение порядка между произвольно раз- 
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мещенньми в памяти объектами, а не только между объектами, хранящимися в од- 
ном и том же массиве. Например, иногда нужно хранить вспомогательную информа- 
цию о каждом объекте и быстро ее извлекать. Упорядоченный ассоциативный массив 
(тар) адресов этих объектов — очень эффективное решение этой проблемы. 

Стандарт языка С++ позволяет легко воплощать такие замыслы. Хотя сравнение 
указателей на.произвольно размещенные объекты не определено, стандарт гарантиру- 
ет, что оператор 514: :1е55 даст осмысленные результаты, если применить его к двум 
указателям, имеющим одинаковый тип. Носкольку стандартные ассоциативные кон- 
тейнеры используют оператор 514: : 1е55 в качестве отношения порядка, заданного по 
умолчанию, можно вполне безопасно пользоваться ассоциативными массивами, клю- 
чами которых являются указатели. 

Класс стагЕРТг также поддерживает эту идиому. Следовательно, класс зтагеРтг 
осуществляет специализацию оператора 514: :1е$$. Эта специализация заключается в 
простой переадресации вызова оператору $14: :1е55 для обычных указателей. 


патеѕрасе 51а 


тетр1асе <с1аѕ5 т> 
$тгист Теѕ5<ѕтагтРЕг<т> > 
: риБ1іс Ьіпағу_Ёипстіоп<Ѕтагтрее<т>, зтагерег<т>, Боої» 


Боо] орегатог() сопѕї ЗтагЕРег<Т>& 1$, 
Соп51 бтагерег<Т>& гі5) соп5і 


гетигп 16е$$<т*>()(бетттр1 (18$), бетттр1(гН$)); 


} 


Итак, класс ЗтагЕРтг не определяет операторы упорядочения по умолчанию. В 
нем объявляются (но не реализуются) два обобщенных оператора <, а остальные опе- 
раторы выражаются через них. Пользователь может использовать либо специализиро- 
ванную, либо обобщенную версии оператора <. 

Класс этагЕРег осуществляет специализацию оператора 54: :1е55, устанавливая 
отношение порядка между произвольными интеллектуальными указателями. 


7.10. Обнаружение и регистрация ошибок 


В разных приложениях требуется разная степень безопасности, обеспечиваемая интел- 
лектуальными указателями. Некоторые программы выполняют интенсивные вычисления, 
поэтому нужно оптимизировать их быстродействие, другие (фактически большинство) ин- 
тенсивно осуществляют операции ввода-вывода информации и нуждаются в эффективных 
средствах проверки данных, не снижающих их производительность. 

Чаще всего в приложении нужны обе модели: низкая безопасность, высокая ско- 
рость в некоторых критических местах и высокая безопасность, низкая скорость — в 
остальных частях программы. 

Вопросы, связанные с проверкой интеллектуальных указателей, можно разделить 
на две категории: инициализация проверки и проверка перед разыменованием. 


7.10.1. Проверка во время инициализации 
Может ли интеллектуальный указатель принимать нулевое значение? 
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Легко можно сделать так, что интеллектуальный указатель никогда не сможет стать 
нулевым (очень полезное свойство в практических приложениях). Это значит, что лю- 
бой интеллектуальный указатель всегда корректен (если вы не манипулируете про- 
стыми указателями с помошью функции бетттр]ке{). Реализовать это свойство ин- 
теллектуального указателя можно с помощью конструктора, генерирующего исключи- 
тельную ситуацию при получении нулевого указателя. 


тетрТате <с1а$$ Т> 
с1а$$ зтагеРЕг 


{ 
риБ1іс: 
ЅѕЅтагїрігСт* р) : роіптее (р) 


ЗРО (1р) тћгом миТПРОЇ пСегЕХСерсіопОО); 


у; 

С другой стороны, нулевое значение представляет собой удобное обозначение 
“неверного указателя” и также часто оказывается полезным. 

Разрешение или запрет нулевых значений влияют и на конструктор по умолчанию. 
Если интеллектуальный указатель не допускает нулевых значений, как конструктор по 
умолчанию может инициализировать обычный указатель? Применения конструктора 
по умолчанию можно избежать, но это значительно затрудняет создание интеллекту- 
альных указателей. Например, что вы будете делать, если у вас есть переменная-член 
класса зтагеРТг, но нет подходящей функции, инициализирующей ее во время соз- 
дания объекта? В заключение отметим, что настройка инициализации содержит выбор 
подходящих значений, задаваемых по умолчанию. 


7.10.2. Проверка перед разыменованием 


Проверка перед разыменованием имеет большое значение, поскольку разыменование 
нулевого указателя приводит к непредсказуемым последствиям. Во многих приложениях 
это совершенно недопустимо, ‘поэтому проверка корректности указателя перед его разы- 
менованием обязательна. В классе зтагЕРтг она выполняется операторами -> и *. 

В отличие от проверки во время инициализации, проверка перед разыменованием мо- 
жет снизить производительность вашего приложения, поскольку обычно разыменование 
интеллектуальных указателей выполняется намного чаще, чем их создание. Следовательно, 
следует стремиться поддерживать баланс между безопасностью и скоростью. Есть хорошее 
правило: начинать со строгой проверки всех указателей, а затем снимать проверку с неко- 
торых интеллектуальных указателей по совету профилировщика. 

Существуют ли принципиальные различия между проверкой во время инициали- 
зации и проверкой перед разыменованием? Нет, так как они связаны между собой. 
Если во время инициализации выполняется строгая проверка, то проверка перед ра- 
зыменованием становится излишней, поскольку указатели, прошедшие проверку во 
время инициализации, всегда корректны. 


7.10.3. Сообщения об ошибках 


Единственный разумный способ регистрировать ошибки — генерировать исключи- 
тельные ситуации. 

Можно предпринять некоторые предосторожности, позволяющие избежать появ- 
ления ошибок. Например, если указатель перел разыменованием оказался нулевым, 
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его можно проинициализировать на лету. Эта правильная и ценная стратегия называ- 
ется ленивой инициализацией (ату іпііаітайоп) — объект создается только в тот мо- 
мент, когда он впервые используется. 

Если проверка должна выполняться только в процессе отладки программы, можно 
использовать стандартный макрос аззегт и подобные ему более сложные макросы. В 
окончательном варианте программы компилятор игнорирует проверки. Следователь- 
но, если все ссылки на нулевые значения во время отладки уже удалены, во время 
выполнения программы проверку можно не повторять. 

В классе Ѕтагїрїг все проверки сосредоточены в стратегии СНесК1пд, реализую- 
щей соответствующие функции (которые при необходимости могут использовать ле- 
нивую инициализацию). 


7.11. Интеллектуальные указатели на константные 
объекты и константные интеллектуальные 
указатели 


Обычные указатели реализуют два вида работы с константами: указатели на кон- 
стантные объекты и собственно константные указатели. Эти свойства укаватолей ил- 
люстрируются следующим фрагментом программы. 


соп5ї Ѕотеїһіпд“* рс = пем Ѕотеїһіпд; // Указывает на 
// константный объект 

рсе-»Соп5 СМетбегЕйпссіоп(); // правильно 

ре-»МмопСоп5 МетьегРЕипстїоп(); // Неправильно 

деїете рс; // Как ни странно, правильно“ 

зотетИ1пд* соп$Е рс = пем Ѕотетһћіпд; // Константньй указатель 

ср-»мопСоп5 тметЬегргипст1оп(); // Теперь правильно 

ср = пем ѕотеїһіпд; // неправильно, константному указателю 
// ничего нельзя присваивать 

соп5і Ѕотеһіпд* сопѕї срс = 

пем Ѕотеїһћїпд; // Константный указатель на константный объект 

срс-»Соп5 СМетрегРЕипссіопО; //Правильно 

срс-ьМопСоп5 ЕМетбегеипсїііоп() · // Неправильно 

срс = пем 5отеспіпд; // Неправильно, константному указателю 
// ничего нельзя присваивать 


Соответственно, класс этагеРсг используется следующим образом. 


// интеллектуальный указатель на константный объект 
этагеРЕГ<соп$& З5отеспіпд» ѕрс(пем Ѕотетћіпд9) ; 

// Константный интеллектуальный указатель 

сопѕї 5тагіРІГ«5отетПпіпд» ѕср(пем Ѕотетћіпд) ; 

// Константный интеллектуальный указатель на константный объект 
соп5т Ѕтагтріг<сопѕт ѕотетћіпд> ѕсрс(пем ѕотетћіпд) ; 


Шаблонный класс ЅтагїрРїг может обнаруживать, является ли объект, на который он 
ссылается, константным, с помощью частичной специализации или шаблонного класса 
туретгаї є5, определенного в главе 2. Второй способ более предпочтителен, поскольку он 
не приводит к дублированию исходного кода, как при частичной специализации. 


4 Вопрос “Почему оператор де1ете можно применять к указателям на константные объек- 
ты?” всегда вызывает яростные споры в группе новостей сотр.519.с++. Однако, хорошо это или 
плохо, язык допускает такую конструкцию. 
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Класс зтагеРТг имитирует семантику указателей на константные объекты, кон- 
стантных указателей, а также их комбинации. | 


7.12. Массивы 


В большинстве случаев вместо динамических массивов и операторов пем[] и де- 
Тесе() лучше использовать стандартный класс 514:;местог. Этот класс полностью 
обеспечивает возможности, предоставляемые динамическими массивами, а также 
многое другое, почти не тратя при этом дополнительных ресурсов. 

Однако “в большинстве случаев” не означает “всегда”. Сушествует много ситуа- 
ций, в которых полноценный вектор не нужен и даже не желателен. Именно здесь и 
нужны динамические массивы. В таких случаях без интеллектуальных указателей 
обойтись трудно. Между сложным шаблонным класом 511: :мессог и динамическими 
массивами пролегает довольно глубокая пропасть. Интеллектуальные указатели могут 
выступать в роли мостиков через эту пропасть, предоставляя пользователю семантиче- 
ские возможности массивов. 

С точки зрения интеллектуального указателя на массив единственным важным момен- 
том является использование вызова оператора де1ете[] роіптее_ в его деструкторе вме- 
сто оператора деТете ро1птее_. Эта проблема уже решена в стратегии Омпег$Н1р. 

Второй момент связан с индексированным доступом к элементам массива с помо- 
щью оператора [], перегруженного для интеллектуальных указателей. Технически это 
вполне возможно. Фактически в предварительной версии класса ѕтагтртг для семан- 
тики массивов была предусмотрена отдельная стратегия. Однако интеллектуальные 
указатели очень редко ссылаются на массивы. В этих случаях индексированный дос- 
туп можно обеспечить с помощью функции бесхтр?. 

Ѕтагтрєг<міддет> 5р = ...; 

// доступ к шестому элементу массива, на который ссылается 

// интеллектуальный указатель ѕр 

міадет& обі = бехттр1 ($р) [5]; 

Было бы нерационально пытаться разработать дополнительные синтаксические кон- 
струкции за счет новой стратегии. 

Класс ѕтагїірєг поддерживает настраиваемое разрушение объектов с помощью 
стратегии Омпег5Н1р. Следовательно, для удаления массивов можно использовать 
оператор де1ете[]. Однако класс Ѕтагтртг не поддерживает арифметику указателей. 


7.13. Интеллектуальные указатели и многопоточность 


Чаще всего интеллектуальные указатели помогают совместно использовать объекты. В 
свою очередь, многопоточность тесно связана с совместным использованием объектов. 
Следовательно, многопоточность и интеллектуальные указатели связаны друг с другом. 

Взаимодействие между ними проявляется на двух уровнях: на уровне объектов, на 
которые ссылаются интеллектуальные указатели (ропиее обес Ісує!), и на уровне ре- 
гистрации данных (рооККееріпе, даа Ісме!). 


7.13.1. Многопоточность на уровне объектов 


Если на один и тот же объект одновременно ссылаются интеллектуальный указа- 
тель и несколько потоков, желательно иметь возможность захватывать этот объект на 
время вызова функции-члена, выполненного с помощью оператора ->. Этого можно 
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достичь, если интеллектуальный указатель будет возврашать объект-заместитель (ргоху 
оріесі), а не простой указатель. Конструктор объекта-заместителя захватывает объект, 
на который ссылается интеллектуальный указатель, а его деструктор освобождает его. 
Этот способ программирования описан в книге Страуструпа (5(гоиѕігир, 2000). Ниже 
приводится код, иллюстрирующий этот подход. 

Во-первых, рассмотрим класс міддес, имеющий две конструкции для захвата объекта: 
функции-члены госК и уп1оск. После вызова функции госк открывается безопасный дос- 
туп к объекту, при этом вызов такой функции остальными потоками блокируется. После . 
вызова функции уп1осКк объект может поступать в распоряжение остальных потоков. 


сТаз5 міддет 


моіа 1оскО; 
уоіа цпТосКО; 
; 
Затем определим шаблонный класс і оскіпдргоху. Он предназначен для захвата 
объекта (с помощью описанного выше механизма госк/ип1оскК) на время существова- 
ния объекта класса госК1паРгоху. 


тетр1ате <с1а55 т> 
сТа55 цосКіпдРгоху 


( О 
рчЬ1іс: 
(оскіпдРгоху(тя робі) : роіпёее_ (рој) 
{ роіпсее _->1оск(); } 
~ГосКіпдргоху() ; 
{ ро1псее_->ип1осКО; } 
Т* орегатог->() сопѕт 
{ гетигп роіптее_; ) 
ргімате: 
госкіпдРгохуб орегатог= (сопѕї цоскіпдРгохув); 
ті ро1птее; ° 
Кроме конструктора и деструктора в классе цоскіпдРгоху определен оператор ->, 
возвращающий указатель на объект. 
Несмотря на то что класс ГосК1пдРгоху напоминает интеллектуальный указатель, 
вокруг него существует еще одна оболочка — сам шаблонный класс ЅтагтрР?г. 


тетр1ате <с1аѕѕ т> 
с1аѕ5 Ѕмагіріг 


{ 


ІосКіпдргоху<т> орегатог-> () сопѕт; 
{ гесигп госКіпдргоху<т> (роіптее_); } 
рг1уахе: 
т? ротпхее_; 
Н 
Напомним, что в разделе 7.3, посвященном механике оператора ->, уже указыва- 
лось, что компилятор может применять оператор -> к одному и тому же выражению 
несколько раз, пока не обнаружит простой указатель. Теперь представьте себе следу- 
щий вызов (считая, что в классе м14дет определена функция ОСоѕотетћіпд). 


Ѕмагірег<№іддет> 5р = ... ; 
ѕ5р->Ооѕотмеїћ1пд() ; 
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Здесь кроется один нюанс: оператор -> класса 5тагтРхг возвращает временный объ- 
ект класа госК1пдРгоху<т>. Компилятор продолжает применять оператор -». Опера- 
тор -> объекта класса оскіпдРгоху<т> возвращает объект, имеющий тип мі 4дет*. 
Компилятор использует этот указатель на объект класса міаддеї для вызова функции 
ро5отесніпд. Во время вызова этой функции объект класса госК1паРгоху<т> про- 
должает существовать и владеть объектом, находящимся в полной безопасности. По- 
сле возврата управления из функции Ооѕотеһіпд временный объект класса 
осКкіпдргоху<т> уничтожается, и объект класса \14де* освобождается. 

Автоматический захват объектов — хорошая иллюстрация расслоения интеллекту- 
альных указателей, которое можно осуществить, внеся соответствующие изменения в 
стратегию 5 огаде. 


7.13.2. Многопоточность на уровне регистрации данных 


Иногда, кроме объектов, на которые они ссылаются, интеллектуальные указатели ма- 
нипулируют дополнительными данными. Как указывалось в разделе 7.5, несколько интел- 
лектуальных указателей с подсчетом ссылок скрытно используют один и тот же счетчик. 
Если скопировать такой указатель из одного потока в другой, возникнут два интеллекту- 
альных указателя, использующих один и тот же счетчик ссылок. Разумеется, они оба про- 
должают указывать на тот же объект, но пользователю известно, какой из этих указателей 
в данный момент владеет им. В то же время счетчик ссылок пользователю не доступен и 
управляется исключительно интеллектуальным указателем. 

Для многопоточной среды опасность представляют не только интеллектуальные указа- 
тели с подсчетом ссылок. Интеллектуальные указатели с отслеживанием ссылок 
(раздел 7.5.4) содержат указатели друг на друга, которые также относятся к совместно ис- 
пользуемым данным. Связывание ссылок объединяет интеллектуальные указатели в груп- 
пу, причем они не обязаны принадлежать одному и тому же потоку. Следовательно, каж- 
дый раз, когда выполняется копирование, присваивание или уничтожение интеллектуаль- 
ного указателя с отслеживанием ссылок, нужно решать вопрос о захвате объекта, в 
противном случае дважды связанный список может оказаться разрушенным. 

В заключение отметим, что вопросы, связанные с многопоточностью, в итоге 
влияют на реализацию интеллектуальных указателей. В качестве примера рассмотрим, 
как многопоточность влияет на подчет ссылок и их связывание. 


7.13.2.1. Многопоточный подсчет ссылок 


При копировании интеллектуальных указателей из разных потоков счетчик ссылок 
в разных потоках увеличивается непредсказуемым образом. 

Как показано в приложении, операция инкрементации не является атомарной. 
Для инкрементации и декрементации целых чисел в многопоточной среде нужно ис- 
пользовать тип Тһгеааіпамоде1 <т> : :тпетуре, а также функции Асотісіпсгетепі и 
АТОТ1 сресгетепт. 

Это все немного усложняет. Вернее, ситуация осложняется, если мы хотим сделать 
подсчет ссылок независимым от потоков. 

Следуя принципам разработки классов на основе стратегий, разложим класс на 
элементы, описывающие его поведение, и свяжем с каждым из них соответствующий 
шаблонный параметр. В идеале класс зтагтРруг задавал бы стратегии Омпег$И1р и 
Тһгеааіпдмойе1, применяя их для корректной реализации. 

Однако при подсчете ссылок в многопоточной среде все намного запутаннее. На- 
пример, счетчик должен иметь тип ТИгеад1пдамоде1<т>: :ІпїТуре. Следовательно, 
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вместо использования операторов ++ и -- приходится применять функции АтотісІп- 
сгетепт и Атотісресгетепт. Потоки и счетчик ссылок сливаются в одно целое, их 
невероятно трудно разъединить. 

Лучше всего включить многопоточность в стратегию Омпег5Нір. В этом случае 
можно получить две реализации: веРСоип*1пд и КеЁсоипе1 помт. | 


7.13.2.2. Многопоточное связывание ссылок 


Рассмотрим деструктор интеллектуального указателя со связыванием ссылок. 


тетр1ате <с1аѕѕ Т> 
сТаѕ5 Зтагертг 


Е 
риБ1іс: 
~Ѕмагіріг() 
1Ғ (ргеу_ == пехт ) 
Пе1ете роіптее_; 
е]5е 
І 
рге\м_->пех*_ = пех\_; 
пехі -»ргем з ргем_; 
) 
) 
ргімате: 


т* ро1птее_; 
Ѕтагірег* ргем_; 
ЅтагірРїг* пехі ; 


; 
Деструктор выполняет классическое удаление элемента из дважды связанного списка. 
Для упрощения и ускорения реализации список сделан кольцевым — последний узел 
ссылается на первый. Это позволяет не проверять, являются ли указатели ргем. и 
пехт_ нулевыми. В кольцевом списке, состоящем из одного элемента, указатели 
ргем_ и пех*_ будут равны указателю «Ні 5. 

Если несколько потоков уничтожают интеллектуальные указатели, связанные друг 
с другом, деструктор, очевидно, должен быть атомарным (т.е. его работу не могут пре- 
рвать другие потоки). В противном случае работу деструктора класса зтагЕРЪг сможет 
прервать любой поток. Например, это может произойти в момент между обновлением 
указателей ргеу_ и пехї_. В этом случае поток, прервавший работу деструктора, будет 
оперировать разрушенным списком. 

Аналогичные рассуждения касаются и конструктора копирования, и оператора 
присваивания класса ЅтагїРїіг. Эти функции должны быть атомарными, поскольку 
они манипулируют со списком владения. 

Интересно, что здесь нельзя применить семантику захвата объектов. В приложе- 
нии, приведенном в конце книги, стратегии захвата разделены на стратегии уровня 
классов (с1аз$ 1еуе] ѕігаїеріеѕ) и стратегии уровня объектов (обіесі-Іеме! ѕїгаіеріеѕ). Опе- 
рации захвата на уровне классов захватывают все объекты данного класса. В то же 
время операции захвата на уровне объектов относятся только к одному объекту. В 
первом случае тратится меньше памяти (только один мьютекс на класс), но возника- 
ют проблемы с производительностью программы. Второй случай (один мьютекс на 
объект) сложнее, но позволяет создавать реализации, которые работают быстрее. 
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К интеллектуальным указателям нельзя применять стратегию захвата на уровне 
объектов, поскольку операция копирования манипулирует сразу тремя объектами: те- 
кущий объект, подлежащий вставке или удалению, предыдущий объект и следующий 
объект в списке владения. 

Если все же возникает необходимость реализовать захват на уровне объектов, сле- 
дует убедиться, что каждому объекту соответствует один мьютекс, поскольку для каж- 
дого объекта существует отдельный список владения. Мьютексы для каждого объекта 
можно разместить в динамической памяти, хотя это сводит к нулю все преимущества 
связывания ссылок над их подсчетом. Связывание ссылок привлекательно именно по- 
тому, что оно не использует динамическую память. - 

В качестве альтернативы можно использовать стратегию внедрения: мьютекс хра- 
нится в объекте, на который ссылается интеллектуальный указатель. Однако сущест- 
вование разумной и эффективной альтернативы — интеллектуальных указателей с 
подсчетом ссылок — вынуждает отказаться от реализации этой стратегии. 

Итак, интеллектуальные указатели, использующие подсчет ссылок или их связы- 
вание, возникают в многопоточной среде. Для реализации безопасной стратегии под- 
счета ссылок необходимы атомарные операции. Для реализации безопасной стратегии 
связывания ссылок нужны мьютексы. Класс зтагЕРтг реализует только безопасную 
стратегию подсчета ссылок. 


7.14. Сборка 


До сих пор мы рассматривали каждый вопрос по отдельности. Настало время со- 
брать все решения воедино и воплотить их в реализации класса зтагЕРТг. 

Мы будем по-прежнему следовать принципам разработки классов на основе стра- 
тегий, описанным в главе 1. Каждый аспект проектирования, не имеющий единст- 
венного решения, реализуется в классах стратегий. Шаблонный класс тагЕРЕг полу- 
чает каждую стратегию в виде отдельного шаблонного параметра, наследует все эти 
шаблонные параметры, позволяя соответствующим стратегиям сохранять состояние. 

Вернемся мысленно к предыдущим разделам, перечисляя основные аспекты класса 
стагЕРТг, каждый из которых представляет собой отдельную стратегию. 


• Стратегия $тогаде (раздел 7.3). По умолчанию сохраняемым типом является 
тип т* (тип т — это первый шаблонный параметр класса ѕтагтртїг), типом ука- 
зателей — тоже ТЯ, а ссылочным типом — т&. Объект, на который ссылается 
интеллектуальный указатель, уничтожается оператором де]ете. 


® Стратегия Омпегѕһір (раздел 7.5). Обычно реализуется с помощью глубокого 
копирования, подсчета ссылок, связывания ссылок и разрушающего копирова- 
ния. Обратите внимание на то, что стратегия Омпегѕћір не связана с механиз- 
мом уничтожения объектов, который относится к стратегии $тогаде. Стратегия 
Омпегѕһір лишь указывает момент уничтожения объекта. 


е Стратегия Сопуегѕіоп (раздел 7.7). В некоторых приложениях необходимо 
преобразовывать интеллектуальные указатели в обычные. Обратное преобразо- 
вание не допускается. 


е Стратегия СпесКіпд (раздел 7.10). Эта стратегия проверяет правильность ини- 
циализации и разыменования класса зтагтРтг. 


Остальные свойства не настолько важны, чтобы создавать для них отдельные стратегии. 


• Оператор взятия адреса (раздел 7.6) лучше не перегружать. 
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® Проверка равенства и неравенства выполняется с помощью приема, описанного 
в разделе 7.8. 


• Отношения порядка (раздел 7.9) остаются нереализованными. Однако в биб- 
лиотеке ГоК! осуществляется специализация функции $14: :1е$$ для объектов 
класса зтагЕРхг. Пользователь может определить оператор <, а библиотека Іокі 
поможет выразить через него остальные операторы сравнения. 


• В библиотеке [о определена корректная реализация константных объектов 
класса Ѕтагертг, объектов, на которые ссылаются интеллектуальные указатели, 
а также их обоих одновременно. 


• Массивы специально не предусматриваются, однако одна из готовых реализа- 
ций стратегии 5 огаде может удалять массивы с помощью оператора ае1ете[]. 


Каждый аспект реализации класса Зтаг%Р%г рассматривался отдельно от осталь- 
ных. Это позволяет лучше разобраться в их механизмах. Намного полезнее разобрать 
реализацию на части и рассмотреть их по отдельности, чем изучать их в комплексе. 

Разделяй и властвуй — этот старый девиз Юлия Цезаря вполне пригоден для раз- 
работки интеллектуальных указателей. (Бьюсь об заклад, он этого не предвидел!) Мы 
разбиваем проблемы на неболышие составные классы, называемые стратегиями 
(ройсу). Каждая стратегия связана только с одним аспектом реализации класса. Класс 
Ѕтагїірег наследует все эти классы, одновременно приобретая все их свойства. Это 
очень простой и невероятно гибкий механизм. Кроме того, каждая стратегия задается 
одним шаблонным параметром. Это позволят смешивать и сопоставлять существую- 
щие классы стратегий, а также создавать на их основе свои собственные стратегии. 

Первым идет тип объекта, на который ссылается интеллектуальный указатель, за 
ним — все стратегии. В итоге получается следующее объявление класса ѕтагїртг. 

тетр1ате 

2 : 
хурепате Т, 
тетр1ате <с1аѕ5> с1аѕ5 Омпегѕһірро1ісу = пеЁсоцптеа, 
с1а$$ Сопуегѕіопро1ісу = ріѕа11омСопуегѕіоп, 
сетр1ате <с1аѕ5> с1аѕ5 СһескКіпдро1ісу = А5Ѕегтсһеск, 
тетр1ате «сТа55» с1аѕѕ Ѕ1огадеро1ісу = беҒац1 «5 Р5тогаде 

> 

сТа55 5тагеЕРЕг; 

Сначала следует указывать стратегии, которые настраиваются чаще. других. 

Ниже рассматриваются требования, предъявляемые к четырем стратегиям, опреде- 
ленным ранее. Все эти стратегии должны иметь семантику значений, т.е. они должны 
определять соответствующие конструктор копирования и оператор присваивания. 


7.14.1. Многопоточность на уровне объектов 

Стратегия 5$тогаде абстрагирует структуру интеллектуального указателя. Она осу- 
ществляет определение типов и хранит фактический объект ро1птее_. 

Если класс 5тогадеттр1 является реализацией стратегии ѕТогаде, а зхогадеттр! — 
это объект типа 5тогадеттр1 <т>, то применяются конструкции, указанные в табл. 7.1. 

Реализация стратегии $тогаде по умолчанию имеет следующий вид. 


тетр1ате <с1а$$ Т> 
сТаѕѕ реҒаи1+5Рѕ?огаде 


рготестеа: 
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хуредеї т* 5їогеайТуре; // Тип объекта роіптее_ 
туреде{ т* Роіптегтуре; // тип объекта, 
// возвращаемого оператором -> 
хуредеї ТА веегепсетуре; // Тип объекта, 
// возвращаемого оператором * 
риБ1іс: 

О БеРац] +5Р5тогаде() : ро1птее_(беРаи1т()) 
реҒаи115рѕТоғгаде (сопѕї Ѕїогейтуре& р): роіптее (р) {} 
РоіптегТуре орегатог-> О сопѕї { гетигп ро1птее_; } 
КеҒегепсеТуре орегатог*() сопѕї { гетигп “роіптее_; р 
Ғгіепа іпТіпе Роіпсегтуре бехттр1 (сопѕт реҒаџ115РЅїогаде& 5р) 
{ гетигп зр.ро1птее_; 

Ғгіепа іпТіпе сопзт ѕтогейтуре& сетІітр1ке#( 
сопѕї реЁаи115рѕтогаде& зр) 
і гетигп ѕр.роіптее_; ) 
Ғгіепа іп1іпе $тоге4Туре& Сетітр1кеЁ(реҒаци115РѕТтогаде& зр) 
{ гетигп ѕр.роіптее_; } 
рготестеа: 
моїй безтгоу() 
{ деТете роїптее ; } 
Ѕтаїтіс Ѕїогеатуре реҒаи1т10) 
{ гетигп 0; ) 
ргімате: 
Ѕтогейтуре роїптее ; 
Кроме класса ребаші т$Р5тогаде в библиотеке Го определены следующие классы. 
• Класс Аггаузтогаде, использующий оператор де1ете[] внутри функции ке1еаѕе. 


• Класс 1 оскейѕтогаде, использующий иерархическую реализацию интеллекту- 
ального класса, захватывающего данные при разыменовании (раздел 7.13.1). 


е Класс Неарѕтогаде, использующий явный вызов деструктора и функцию 
$14: : Ғгее для освобождения данных. 


Таблица 7.1. Конструкции стратегии Ѕїогаде 


Выражение Семантика 


Ѕтогадеїтр1<т> : : $фогедтуре Тип, фактически хранимый реализацией. По 
умолчанию: т* 


5тогадеттр1<т>: : Ро1птегтуре Тип указателей, определенный реализацией. 
Возвращается оператором ->, определенным в 
классе бтагЕРЕг. По умолчанию: Т*. Может 
отличаться от типа $тогадеттр1<Т>: : $тогедТуре, 
если используется иерархия интеллектуальных 
указателей (разделы 7.3 и 7.13.1) 


$тогадеттр1<т> : : кеЁегепсетуре Ссылочный тип. Возвращается оператором * 
: класса 5таг'єРСГ. По умолчанию: Те 


бетттр1 (5 согадеттр1) Возвращает объект типа 
ЅїогадеїІтр1<т>: : зтогедтуре 
бетттр1 ке? (5 согадеттр1) Возвращает объект типа 


5 гогадеттр1і«т»: : зтогейдтуре& (если объект 
з гогадеттр является константным, 
конструкция объявляется константной) 
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Окончание табл. 7.1 
Выражение Семантика 


5тогадеттр1 .орегатог-> () Возвращает объект типа 
ЅтогадеїІтр1<т>; : : Роіпсегтуре. Используется 
оператором -> класса бтагЕРЕГ 


ѕтогадеїтр1 .орегатог* 0 Возвращает объект типа 
ЅтогадеїІтр1<т> : : КеРегепсетуре. 
Используется оператором * класса зтагЕРЕГ 


Ѕ№огадеїтр1 <т>: : $тогедтуре р; Возвращает значение, заданное по умолчанию 
р = ѕТогадеїІтр1.реҒаи1+() ; (обычно нуль) 
ѕтогадеїтр1 .реѕтгоу() Разрущает объект, на который ссылается 


интеллектуальный указатель 


7.14.2. Стратегия Омпегѕћһір 


Стратегия Омпегѕћір должна поддерживать как внедренный, так и независимый 
полсчет: ссылок. Следовательно, она должна использовать явные вызовы функции, а 
не механизм конструкторов и деструкторов, как это сделано в работе (Коепіє, 1996). 
Дело в том, что функцию-член можно вызвать в любое время, а конструкторы и дест- 
рукторы вызываются автоматически и только в определенные моменты времени. 

Реализация стратегии Омпег5Нір имеет один шаблонный параметр, соответствующий 
ссылочному типу. Класс зтагЕРЕг передает параметр 5 огадерої ісухТ»: : Ро1итегтуре 
классу Омпегѕһћірро1ісу. Обратите внимание на то, что шаблонный параметр класса Омп- 
егѕһірро11су является типом указателя, а не объекта, на который он ссылается. 

Если класс Омпегѕһірітр1 является реализацией стратегии Омпегѕћір, а омпег- 
ЅһірІтр1 — это объект типа Омпег$И7рттр1<Р>, то применяются конструкции, ука- 
занные в табл. 7.2. 


Таблица 7.2. Конструкции стратегии Омпегѕћір 


Выражение Семантика 


Р ма11; | Клонирует объект. Может модифицировать 
Р \а12 = ОмпегѕһірІтр1.С1опе(уа11); исходное значение, если в стратегии 


Омпегѕһћір применяется разрушающее 


копирование 
СОП5Т Р уа11; . Клонируєт обьект 
Р маї2 = омпегѕһірІтр1. 
СТопе(ма)1); 
Р уа]; у , Освобождает объект. Возвращает значение 
Боо1 ипідие = омпег5Нірітрї. тгце, если была освобождена последняя 
кеТеа5е(уаї); ссылка на объект 
роо1 ас = Оупег5Пірітрі«Р»:: Устанавливаєт, должна ли стратегия 
дез гистімесСору; омпегѕһір применять разрушающее 


копирование. Если да, класс ЅмагїрРїг 
применяет примем Колвина- Гиббонса 
(Меуегѕ, 1999), использованный в классе 
510: ато рег 


нач 
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Реализация стратегии Омпегѕһір, основанной на подсчете ссылок, выглядит сле- 
дующим образом. 

хетрТасе «сТа55 Р» 

сТа55 веРСоиптед 


ипѕідпеа іпс? рсоипт_; 

рготестеа: 
вевСойпсед 0 : рСоипт_(Спем ипѕідпеа іпеС1)) {} 
Р СТопе(сопѕт Р & ма1) 


++*рбоип®_; 
гетигп ма); 


} 

ђоо1 ВеТеазе(соп5г Р&) 
ЇР С! --*рсСоипт_) 
{ 


деТете рСоипе_; 
гетигп гие; 


гетигп Ёа1ѕе; 


епит { деѕїгисїіуеСору = Ға1ѕе } ; // см. ниже 
Реализовать эту стратегию на основе других схем подсчета ссылок так же просто. 
Рассмотрим реализацию стратегии Омпегѕћір для СОМ -объектов. Эти объекты имеют 
две функции: дааге#Ғ и Ве1еаѕе. При последнем вызове функции ве]еазе объект раз- 
рушается. Нужно лишь передать адрес функции СТопе в качестве параметра функции 
дддвеї и адрес функции ке]еазе в качестве параметра функции ве1еаѕе, принадле- 
жащей СОМ-объекту. 


тетр1ате <с1а$$ Р» 
с1аѕѕ Сомке#соиптеа 


риБ1їс: 
ѕтаїіс Р С1опе(сопѕї Р& ма1) 


ма1->Аааве#(); 
гетигп маї; 


зхасіс Боої веТеазе(соп5С Р& уа1) 


уа1->ве1еа5е(); 
гетиги Ға1ѕе; 


епит { дӢеѕігисїііуеСору = Раїзе }; // см. ниже 
В библиотеке Г.оК1 определены следующие реализации стратегии Омпег5Нір. 


• Класс реерсору, описанный в разделе 7.5.1. В нем предполагается, что в классе, 
на объекты которого ссылается указатель (ропієє с1аѕѕ), реализована функция- 
член СТопе. 


• Класс веРсоиптед, описанный в разделе 7.5.3 и в данном разделе. 
• Класс ве Соиптедмт, многопоточная версия класса веСоиптеа. 


• Класс Сомке#соиптеа — вариант внедренного подсчета ссылок, описанный в 
данном разделе. 
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• Класс Веб| їпКеай, описанный в разделе 7.5.4. 
• Класс бе5 сгиссі уеСору, описанный в разделе 7.5.5. 


• Класс моСору, который не определяет функцию С1опе, блокируя любой вид 
копирования. 


7.14.3. Стратегия Сопуегѕіоп 


Это довольно простая стратегия: она определяет булевскую статическую константу, 
значение которой зависит от того, разрешено в классе ЗтагЕРХг неявное преобразо- 
вание в базовый тип указателя или нет. 

Если класс Сопмегѕіоп1тр1 является реализацией стратегии Сопуегѕіоп, приме- 
няются конструкции, приведенные в табл. 7.3. 

Базовый тип указателя класса $таг®Рег определяется стратегией $тогаде и клас- 
сом 5тогадеттр1<Т> : : Ро1птегтуре. 

Как и следовало ожидать, в библиотеке Го точно определены две реализации 
стратегии Сопуе5 г іоп. 


• Класс А11омСопуегѕіоп. 


• Класс оіѕа11омСопуегѕіоп. 


Таблица 7.3. Конструкции стратегии Сопчегѕіоп 


Выражение Семантика 
роо] а11омсопу = Если константа а] Том имеет значение Тгие, класс 
Сопмег51іопІтр1<Р> : :а11ом; ЅтагірРі г допускает неявное преобразование в 


базовый тип указателя 


7. 14.4. Стратегия СҺескіпо 


Как указывалось в разделе 7.10, проверять объекты класса ѕтагїрРїг можно во 
время инициализации и перед разыменованием. Во время проверки можно использо- 
вать макрос аѕѕегтї, исключительные ситуации, ленивую инициализацию или вообще 
ничего не делать. | 

Стратегия СНесК1пд оперирует классом $тогедтуре, принадлежащим стратегии $тог- 
аде, а не типом Ро1птегтуре. (Определение стратегии $тогаде дано в разделе 7.14.1.) 

Если $ — это сохраняемый тип, определенный в реализации стратегии Ѕїіогаде, 
класс СһескІтр1 реализует стратегии СНесК1па, а сһескіпдїтр1 — это объект типа 
СпесКіпдттрі «5», то применяются конструкции, указанные в табл. 7.4. 


Таблица 7.4. Конструкции стратегии Сһескіпд 


Выражение Семантика 


5 уаТие; Объект класса ѕпагїртег вызывает функцию Оп- 

сһескіпдТтр1.Оп0еҒаџ1 т(ма1ие); реғаџ1+ при вызове конструктора по умолчанию. 
Если в классе СһескіпаІтр1 эта функция не 
определена, конструктор по умолчанию 
блокируется на этапе компиляции 


5 маТие; | Объект класса 5тагЕРТи вызывает функцию Оп- 
сһескіпдІтр1 .ОпІпіт(ма1ие); Іпіт при вызове конструктора 
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Окончание табл. 7.4 


Выражение Семантика 

5 ма че; Объект класса тагтРтг вызывает функцию Оп- 

и п91тр1 -ОпрегеРегепсе регеҒегепсе перед возврашением результата 
уа1ие) ; выполнения операторов -> и * 

СОП5Е 5 маТие; Объект класса ѕмагїіРіг вызывает функцию Оп- 

о пари .ОпрегеРегепсе регебегепсе перед возвращением результата 
маТие); 


выполнения константных версий операторов -> и Ы 


В библиотеке [окі определены следующие реализации стратегии сһескіпд. 


• Класс дззегтСНеск, использующий макрос аѕѕегї для проверки значения пе- 
ред разыменованием. 


« Класс Аѕ5егтСһескКѕтгіскі, использующий макрос а55егт для проверки зна- 
чения при инициализации. 


« Класс вејесїми115татіс, не определяющий функцию ОпреҒаи1+. Следова- 
тельно, любая попытка вызвать конструктор по умолчанию в классе стагЕРтг 
приведет к появлению ошибки компиляции. 


• Класс вејестми11, возбуждающий исключительную ситуацию при попытке ра- 
зыменования нулевого указателя. 


® Класс ке)естми115сгіст, не позволяющий использовать нулевой указатель в 
качестве начального значения (генерируя при этом исключительную ситуацию). 


• Класс МоСпесК, обрабатывающий ошибки в лучших традициях языков С и 
С++, т.е. не проверяющий их совсем. 


7.15. Резюме 


Поздравляем! Вы добрались до конца самой длинной и обширной главы. Надеемся, 
ваши усилия были не напрасны. Теперь вы многое знаете об интеллектуальных указателях 
и вооружены лаконичным и легко настраиваемым шаблонным классом ЅтагїРїг. 

Интеллектуальные указатели имитируют синтаксис и семантику простых указателей. 
Кроме того, они решают многие задачи, выходящие за пределы возможностей простых 
указателей. Эти задачи могут включать управление владением и проверку значений. 

Концепция интеллектуальных указателей намного шире простых указателей. Она 
может быть обобщена до уровня интеллектуальных ресурсов, например, моникеров 
(дескрипторов, напоминающих указатели, но имеющих иной синтаксис). 

Поскольку интеллектуальные указатели легко автоматизируют процессы, которые 
практически невозможно реализовать вручную, они стали важным компонентом со- 
временных приложений, от которых требуется особая надежность. Именно от них за- 
висит, будет программа выполнена успешно или ее работа приведет к угечке ресурсов. 

Вот почему разработчики интеллектуальных указателей должны уделять им особое 
внимание. Со своей стороны программисты, использующие интеллектуальные указа- 
тели, должны хорошо понимать правила работы с ними и точно им следовать. 

Представляя реализацию интеллектуальных указателей, мы уделяли основное вни- 
мание вопросу декомпозиции функциональных возможностей на независимые стра- 
тегии, которые можно сопоставлять и смешивать в классе Ѕтагтртг. Возможно по- 
этому, каждая стратегия реализует тщательно продуманный интерфейс. 
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7.16. Краткий обзор класса ЅтагїРїг 
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Объявление класса ѕмагїрРіг 


тетр1ате 

< 

Турепате т, 

тетр1ате <с1а$$> с1аѕ5 Омпегѕһірро1ісу = ВеЁсоиптеа, 
сТа55 СопуегѕіопРо1ісу = ріѕа1Л1омсопуегѕіоп, 
тетрЛ1ате <с1а55> с1аѕѕ СһескКіпдро1ісу = Аѕѕегтсһеск, 


тетр1ате <с1аѕѕ> с1а55 ѕтогадеро1ісу = реѓаи1т5рРѕТогаде 
а 


сТа55 5пагтРЕГ; 


т — это тип, на который указывает объект класса 5тагіРЕг. Тип Т может быть ос- 
новньм или определяться пользователем. Допускается использование типа усій. 


Для оставшихся параметров шаблонного класса (Омпег$Н1рРо11су, Сопуег- 
5іопРО1ісу, СһесКіпдро11ісу и ѕтогадеро1ісу) можно реализовать свои собст- 
венные стратегии или выбирать их по умолчанию, как показано в разделах 
7.14.1—7.14.4. 


Шаблонный параметр Омпегѕһірро1ісу задает стратегию владения. В качестве та- 
кой стратегии можно выбирать классы беерСору, ВеРСоипте4, КеҒсоиптедмт, сом- 
КеҒСоиптеа, веб. іпКед, резтгист1уеСору и МоСору, описанные в разделе 7.14.2. 


Шаблонньй параметр СопуегѕіопРо1ісу устанавливает, допускается ли неяв- 
ное преобразование в базовый тип указателя. По умолчанию неявное преобра- 
зование запрещено. В любом случае доступ к объекту осуществляется с помо- 
щью вызова функции беїІтр1. В качестве реализации стратегии можно исполь- 
зовать классы А11о0мСопуег5їоп и ріѕа11омСопуегѕіоп (раздел 7.14.3). 


Шаблонньй параметр СпесКіпдРої ісу задает стратегию проверки ошибок. По 
умолчанию можно использовать классы АѕѕегіСһесКк, Аѕѕегісһескѕігіст, Ве- 
јести 15 сасіс, Ведес*Ми\ 15 г1с& и МоСпесі (раздел 7.14.4). 


Шаблонньй параметр $ТогадеРро11су определяет механизм хранения и доступа к 
объекту. По умолчанию применяется класс реҒаи1тѕрѕтогаде, который, будучи 
конкретизирован типом т, определяет ссылочный тип Тб, сохраняемый тип тя, а 
также тип Т*, возвращаемый оператором ->. В библиотеке Го определены также 
сохраняемые типы Аггауѕтогаде, госкедзтогаде и Неарѕтогаде (раздел 7.14.1). 
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ФАБРИКИ ОБЪЕКТОВ 


Для достижения высокого уровня абстракции и модульности в объектно- 
ориентированных программах применяются механизм наследования и виртуальные функ- 
ции. Полиморфизм, предоставляющий возможность отложить выбор вызываемой функ- 
ции на период выполнения программы, обеспечивает повторное использование бинарного 
кода и его адаптацию. Система поддержки выполнения программ автоматически распреде- 
ляет виртуальные функции по соответствующим объектам производных классов, позволяя 
описать сложное поведение с помощью полиморфных примитивов. 

Параграф, приведенный выше, можно найти в любой книге, посвященной объект- 
но-ориентированному программированию. Мы цитируем эти высказывания для того, 
чтобы проиллюстрировать контраст между благополучным состоянием дел в 
“стационарном режиме” и сложной ситуацией, складывающейся в “режиме инициа- 
лизации”, когла объект нужно создавать с помошью полиморфных методов. 

В стационарном режиме у нас уже есть указатели или ссылки на полиморфные 
объекты, и мы можем вызывать соответствующие функции-члены. Их динамический 
тип хорошо известен (хотя вызывающий модуль может его не знать). Однако сущест- 
вуют случаи, когда при создании объектов нужна такая же гибкость. Это приводит к 
парадоксу “виртуальных конструкторов”. Виртуальные конструкторы необходимы, 
когда информация о создаваемом объекте носит динамический характер и не может 
быть использована в конструкциях языка С++ непосредственно. 

Чаще всего полиморфные объекты создаются в динамической памяти с помощью 
оператора пем. 


сТа55 Вахе {... }; 
сТбаз55 регімед : риб11їс вазе { ... У); 
сТа55 Апоїћегрегіуеа : риБ1іс Ваѕе { ... У; 


// создаем объект класса регіуеа и присваиваем его адрес 

// указателю на класс Ваѕе 

Ваѕе* рв = пем регімеа; 
Проблема возникает оттого, что фактический тип регімей указывается непосредственно в 
вызове оператора пем. Между прочим, класс Бегімеа здесь играет ту же роль, что и явно 
заданные числовые константы, которых следует избегать. Если нужно создать объект типа 
Апоїһегрегіуей, приходится изменять соответствующий оператор и изменять тип 
регіуеа на Апоїћегрегіуеа. Сделать этот процесс динамическим невозможно: оператору 
пем можно передавать только типы, точно известные во время компиляции. 

В этом заключается принципиальная разница между созданием объектов и вызо- 
вом виртуальных функций-членов в языке С++. Виртуальные функции-члены явля- 


ў 


ются динамическими — их поведение можно изменять, не модифицируя вызываю- 
щий код. В противоположность этому, каждое создание объекта — это камень пре- 
ткновения для статического, жестко определенного кода. В результате вызовы вирту- 
альных функций связывают вызывающий код только с интерфейсом (базовым клас- 
сом). Объектно-ориентированное программирование стремится снять ограничения, 
накладываемые необходимостью указывать фактический тип создаваемого объекта. 
Однако, по крайней мере в языке С++, создание объектов по-прежнему связывает 
вызывающий код с конкретным классом, находящимся на самом дне иерархиии. 

На самом деле эта проблема намного глубже: даже в повседневной жизни создать нечто 
и пользоваться им — совершенно разные вещи. Обычно предполагается, что, создавая оп- 
ределенный объект, вы точно знаете, что будете с ним делать. И все же иногда в этом пра- 
виле возникают исключения. Это происходит в следующих ситуациях. 


- Если точное знание о каком-то объекте нужно передать другой сущности. Напри- 
мер, вместо непосредственного вызова оператора пем можно вызвать виртуальную 
функцию Сгеате, принадлежащую объекту более высокого иерархического уровня, 
позволяя пользователям изменять его поведение с помощью полиморфизма. 


• Если знания об объекте не могут быть выражены с помощью средств языка 
С++. Например, пусть задана строка "регіуей". В этом случае программист 
точно знает, что нужно создать объект типа регімей, однако эту строку невоз- 
можно передать оператору пем в качестве имени типа. 


Для решения этих принципиально важных задач предназначены фабрики объек- 
тов. В этой главе обсуждаются следующие темы. 


. Ситуации, в которых необходимы фабрики объектов. 

• Почему виртуальные конструкторы трудно реализовать в языке С++. 
• Как создавать объекты, задавая их типы в виде значений. 

• Реализация обобщенной фабрики объектов. 


В конце главы мы построим обобщенную фабрику объектов. Ее можно настраи- 
вать по типу, способу создания и методу идентификации объектов. Фабрику объектов 
можно использовать в сочетании с другими компонентами, описанными в этой книге, 
например, синглтонами (глава б) — для создания фабрики объектов внутри приложе- 
ния и функторами (глава 5) — для настройки работы фабрики. Мы рассмотрим фаб- 
рику клонов, которая может создавать дубликаты объектов любого типа. 


8.1. Для чего нужны фабрики объектов 


Фабрики объектов нужны в двух случаях. Во-первых, когда библиотека должна не 
только манипулировать готовыми объектами, но и создавать их. Например, представь- 
те себе, что мы разрабатываем интегрированную среду для многооконного текстового 
редактора. Поскольку эта среда должна быть легко расширяемой, мы предусматриваем 
абстрактный класс роситепт, на основе которого пользователи могут создавать произ- 
водные классы Техїіроситепті и нтмі ооситепт. Другой компонент интегрированной 
среды — класс роситепїмападег, хранящий список всех открытых документов. 

Следует установить правило: каждый документ, существующий в приложении, 
должен быть известен классу роситепїМмападег. Следовательно, создание нового до- 
кумента тесно связано с его вставкой в список документов, хранящийся в классе 


218 Часть 1. Компоненты 


босимепїмападег. Когда две операции настолько тесно связаны, лучше всего описать 
их с помощью одной и той же функции и никогда не выполнять по отдельности. 


с1аѕ5 роситепїМмападег 


{ 
риБЛ1с: 
роситепт* Меубоситепс 0; 
ргімате: 
уігтиа1 роситепся Сгеатероситепе() = 0; 
з5схд::1і5с«0роситепся» 11570Ғросѕ_; 
$; 
роситеп{* боситептмападег: : Мембоситепт 0 
{ 
Оосимепї* ррос = Сгеатеросимепї 0; 
115 тоҒросѕ_. риѕћ_Баск (рос) ; 
гетигп ррос; 
} 


Функция-член Сгеатебоситепт заменяет вызов оператора пем. Функция-член 
мембоситепі не может использовать оператор пем, поскольку при написании класса 
роситептМмападег еще неизвестно, какой конкретно документ будет создан. Для того 
чтобы использовать интегрированную среду, программист создает производный класс 
на основе класса Юроситептмападег и замещает виртуальную  функцию-член 
Сгеатероситепт (которая должна быть чисто виртуальной). В книге СоЕ (Сатта еї 
а1., 1995) метод Сгеатероситепт называется фабрикой (Ќасїогу теїпоа). 

Поскольку в производном классе точно известен тип создаваемого метода, опера- 
тор пем можно вызывать непосредственно. Таким образом, в интегрированной среде 
не обязательно хранить информацию о типе создаваемого документа и можно опери- 
ровать только базовым классом боситепт. Замещение функций-членов осуществляет- 
ся очень просто и, по сути, сводится к вызову оператора пем. 


роситепї* сгарй1сросимептмападег: : Сгеатероситепт () 


гесигп пем Сгарћі сроситепї; 


В то же время приложение, построенное на основе этой интегрированной среды, 
может поддерживать создание нескольких типов документов (например, растровую и 
векторную графику). В этом случае замещенная функция-член Сгеаїероситепї может 
выводить на экран диалоговое окно, предлагая пользователю ввести конкретный тип 
создаваемого документа. 

Открытие документа, ранее сохраненного на диске, создает новую и более слож- 
ную проблему, которую можно решить с помощью фабрики объектов. Записывая объ- 
ект в файл, его фактический тип следует сохранять в виде строки, целого числа или 
какого-нибудь идентификатора. Таким образом, хотя информация о типе сушествует, 
форма ее хранения не позволяет создавать объекты языка С++. 

Эта задача носит общий характер и связана с созданием объектов, тип которых оп- 
ределяется во время выполнения программы: вводится пользователем, считывается из 
файла, загружается из сети и т.п. В этом случае связь между типом и значениями еще 
глубже, чем в полиморфизме: используя полиморфизм, сущность, манипулирующая 
объектом, ничего не знает о его типе; однако сам объект имеет точно определенный 
тип. При считывании объектов из места их постоянного хранения тип отрывается от 
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объекта и должен сам преобразовываться в некий объект. Кроме того, считывать объ- 
ект из места его хранения следует с помощью виртуальной функции. 

Создание объектов из “чистой” информации о типе и последующее преобразова- 
ние динамической информации в статические типы языка С++ — важная проблема 
при разработке фабрик объектов. Она рассматривается в следующем разделе. 


8.2. Фабрики объектов в языке С++: классы и объекты 


Чтобы найти решение проблемы, нужно хорошо в ней разобраться. В этом разделе 
мы попытаемся найти ответы на следующие вопросы. Почему конструкторы в языке 
С++ имеют такие жесткие ограничения? Почему в самом языке нет гибких средств 
для создания объектов? 

Поиск ответа на эти вопросы приводит нас к основам системы типов языка С++. 
Рассмотрим следующий оператор. 


Ваѕе* рв = пем регіуеа; 


Для того чтобы понять, почему он имеет настолько жесткие ограничения, нам нужно 
ответить на два вопроса. Что такое класс и что такое объект? Эти вопросы вызваны 
тем, что основной причиной неудобств в приведенном выше операторе является имя 
класса бегіуеа, которое требуется явно задавать в операторе пем, хотя мы бы пред- 
почли представить это имя в виде значения, т.е. объекта. 

В языке С++ классы и объекты — совершенно разные сушности. Классы создаются 
программистом, а объекты — программой. Новый класс невозможно создать во время вы- 
полнения программы, а объект невозможно создать во время компиляции. Классы не 
имеют статуса: их нельзя копировать, хранить в переменной или возвращать из функции. 

Существуют языки, в которых классы являются обоектами. В этих языках некото- 
рые объекты с определенными свойствами по умолчанию рассматриваются как клас- 
сы. Следовательно, в этих языках во время выполнения программы можно создавать 
новые классы, копировать их, хранить в переменных и т.д. Если бы язык С++ был 
одним из таких языков, можно было бы написать примерно такой код. 


// предупреждение — это НЕ С++ 

// Будем считать, что СТа55 — это класс и объект одновременно 
СТа55 Веад4(соп${ спагх ҒіЛемате) ; 

роситепё* роситепїмападег: :Орепбоситеп* (сопѕї сНаг* Р1Темате) 


{ 


СТазз СПпеСТаз5 = КеаасҒі Лемапе) ; 
роситепс* ррос = пем СПеСТа55; 


} 


Таким образом, переменную типа С1аѕ5 можно было бы передавать оператору пем. В 
рамках этой парадигмы передача известного имени класса оператору пем ничем не 
отличалась бы от явного указания константы. 

В таких динамических языках за счет потери гибкости достигнут определенный 
компромисс между типовой безопасностью и эффективностью, поскольку статическая 
типизация — это важный компонент оптимизации кода. В языке С++ принят прямо 
противоположный подход — опора на статическую систему типов, позволяющая дос- 
тигать максимальной гибкости. 

Итак, создание фабрик объектов в языке С++ представляет собой сложную задачу. 
В языке С++ между типами и значениями лежит пропасть: значение имеет тип, но 
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тип не может существовать сам по себе. Для создания объекта чисто динамическим 
способом нужно иметь средства для выражения “чистого” типа, передачи его во 
внешнюю среду и создания значения на основе этой информации. Поскольку это не- 
возможно, нужно как-то выразить типы с помощью объектов — целых чисел, строк и 
т.п. Затем следует придумать способы идентификации типов и создания на их основе 
соответствующих объектов. Формула объект-тип-объект лежит в основе создания фаб- 
рик объектов в языках со статической типизацией. 

Объект, идентифицирующий тип, мы будем называть идентификатором типа (буре 
іаепіібег) (Не путайте его с ключевым словом туре1іа.) Идентификатор типа позволяет 
фабрике объектов создавать соответствующий тип. Как мы увидим впоследствии, иногда 
идентификатор типа можно создавать, ничего не зная о том, что у нас есть и что мы полу- 
чим. Это похоже на сказку: вы не знаете точно, что означает заклинание (и пытаться это 
узнать бывает небезопасно), но произносите его, и волшебник возврашает вам полезную 
вещь. Детали этого превращения знает только волшебник..., Т.е. фабрика. 

Мы построим простую фабрику, решающую конкретную задачу, рассмотрим ее 
разные реализации, а затем выделим ее обобщенную часть в шаблонный класс. 


8.3. Реализация фабрики объектов 


Допустим, что мы созлаем приложение для рисования, позволяющее редактировать 
простые векторные рисунки, состоящие из линий, окружностей, многоугольников и 
т.п. В рамках классической объектно-ориентированной парадигмы мы определяем 
абстрактный класс 5Паре, из которого будут выведены все остальные фигуры. 


сТа55 5Паре 


риб11с: 
уігтџа1 уо1 ргам() сопѕт = 0; 
уігіца1 моїй вотате(дои Ле апд1е) = 
уігтиа1 моіа 2оом(аоиБ1е Е 


Б 

Затем можно определить класс Огаміпд, содержащий сложный рисунок. По суше- 
ству, этот класс хранит набор указателей на объекты класса 5Наре, т.е. список, вектор 
или иерархическую структуру, и обеспечивает выполнение операций рисования в це- 
лом. Разумеется, нам понадобится сохранять рисунки в файл и загружать их отгуда. 

Сохранить фигуру просто: нужно лишь предусмотреть виртуальную функцию 
Ѕһаре: : бауе (5+4: :оѕїгеат&). Операция Огаміпд: :5аме может выглядеть следую- 
щим образом. 


с1а$$ Огам1па 
1 
рчБ11с: 
уоїд баме($14: : озтгеат& осисЕїТе): 
уоїд оаа (51а: : 1Ртгеам& іпғі1е); 
Б 


уоїд Огам1 пд: : ѕауе ($14: : оР5тгеат& оитЕі1е) 


1 Эта разработка в духе “Здравствуй, мир!” — хорошая основа для проверки знания языка 
С++. Многие пробовали в ней разобраться, но лишь некоторые из них поняли, как объект за- 
гружается из файла, что, в общем-то, не самое важное. 
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записываем заголовок рисунка 
Ғог (для каждого элемента рисунка) 


{ 


(текущий элемент) -»5аме (оисеї 1е); 


) 


Описанный выше пример часто встречается в книгах, посвященньх языку С++, 
включая классическую книгу Б. Страуструпа (Ѕїгоиѕігир, 1997). Однако в большинстве 
книг не рассматривается операция загрузки рисунка из файла, потому что она разру- 
шает целостность этой прекрасной на вид модели. Углубление в детали загрузки ри- 
сунка заставило бы авторов написать большое количество скобок, нарушив гармонию. 
С другой стороны, именно эту операцию мы хотим реализовать, поэтому нам придет- 
ся засучить рукава. Проше всего потребовать, чтобы в начале каждого объекта класса, 
производного от класса ѕћаре, хранился целочисленный уникальный идентификатор. 
Тогда код для считывания рисунка из файла выглядел бы следующим образом. 


// Уникальный ТО для каждого типа изображаемого объекта 
патеѕрасе Огам'і пдтуре 


соп5с іп 
ІШІМЕ = 1, 
РОЁУСОМ = 2, 
СТВСЬЕ = 3 


у014 Огам1пд: :оа9 ($514: :1Е5тгеам& іпЕї 1е) 


// обработка ошибок для простоты пропускается 
мһіЛе Сіпғ11е) 


// Считываем тип объекта 
іпі фгаміподтуре; 
іпЕЇТе >> дгаміпдтуре; 


// Создаем новый пустой объект 
Ѕһаре* рСиггепсобіест; 
ѕміїсћһ (агаміпатуре) 


и5іпу патеѕрасе ргам1пдтуре; 

саѕе іІМЕ: 
рСиггепїоБјесї = пем і іпе; 
ргеак; 

саѕе РОЦУСОМ: 
рсиггептобјест 
ргеак; 

саѕе СІВСІЕ: 
рсиггептобјесї = пем С1ігс1е; 
Ьгеак; 

деҒаи1т: 


обработка ошибки — неизвестный тип объекта 


пем РОТудоп; 


// Считываем содержимое объекта, 
// вызывая виртуальную функцию п 
рсиггептобјест->веааСіпғі1е) ; 
добавляем обьект в контейнер 
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Это настоящая фабрика объектов. Она считывает из файла идентификатор типа, 
основываясь на этом идентификаторе, создает объект соответствующего типа и вызы- 
вает виртуальную функцию, загружающую этот объект из файла. Одно плохо: все это 
нарушает важные правила объектно-ориентированного программирования. 


• Выполняется оператор ѕміїсһ, основанный на метке типа со всеми вытекаю- 
щими отсюда последствиями. Именно это категорически запрещено в объект- 
но-ориентированных программах. 


• В одном файле концентрируется информация обо всех классах, производных от 
класса 5Наре, что также нежелательно. Файл реализации функции Огам- 
іпд: :бауе вынужден содержать все заголовки всех возможных фигур. Это дела- 
ет его уязвимым и зависимым от компилятора. 


® Класс трудно расширить. Представьте себе, что нам понадобилось добавить но- 
вую фигуру, скажем, класс Е11ірѕе. Кроме создания нового класса, придется 
добавить новую целочисленную константу в пространство имен ргаміпдтТуре, 
записать ее при сохранении объекта класса Е11ірѕе и добавить новую метку в 
оператор ѕміїсһ внутри функции-члена огам1 пд: : 5аме. И все это ради одной- 
единственной функции! 


Попробуем создать фабрику объектов, лишенную указанных недостатков. Для этого 
придется отказаться от использования оператора ѕміїсћһ, чтобы мы могли выполнять опе- 
рации по созданию объектов классов 11пе, РОТудоп и Сі гс1е единообразно. 

Для того чтобы связать между собой фрагменты кода, лучше всего использовать указа- 
тели на функции, описанные в главе 5. Фрагмент настраиваемого кода (каждый из эле- 
ментов оператора ѕміїсһ) можно абстрагировать с помощью следующей сигнатуры. 


Ѕһаре* сгеатесопсгетеѕһаре 0) ; 


Фабрика хранит набор указателей на функции вместе с сигнатурами. Кроме того, 
нужно установить соответствие между идентификатором типа и указателем на 
функцию, создающую объект. Таким образом, нам нужен ассоциативный массив 
(тар), предоставляющий доступ к соответствующей функции по идентификатору 
типа (именно то, что делал оператор ѕміїсһ). Кроме того, этот массив гарантиру- 
ст масштабируемость, чего оператор ѕміёсһ с его фиксированной статической 
структурой обеспечить не может. Во время выполнения программы ассоциатив- 
ный массив может возрастать — мы можем динамически добавлять в него новые 
элементы (кортежи, состоящие из идентификаторов типов и указателей на функ- 
ции), а именно это нам и нужно. Можно начать с пустого массива, а затем каж- 
дый объект класса, производного от класса 5Варе, добавит в него новый элемент. 

Почему нельзя использовать вектор? Идентификаторы типов являются целыми 
числами, поэтому их можно считать индексами вектора. Это проще и быстрее, но 
ассоциативный массив все же лучше. Индексы в таком массиве не обязаны быть 
смежными. Кроме того, в векторе индексы могут быть только целыми числами, в 
то время как индексом ассоциативного массива может быть любой тип, для кото- 
рого установлено отношение порядка. При обобщении нашего примера этот факт 
приобретает особое значение. 

Начнем с разработки класса ѕһареғастоғу, предназначенного для создания всех 
объектов классов, производных от класса паре. В реализации класса 5нареЕасіогу 
мы будем использовать ассоциативный массив из стандартной библиотеки 5 4: : тар. 


сТа55 5$Парерасхогу 
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риБЛ1с: 
суредеҒ 5Наре*“ (*Сгеатеѕһареса11Ьаск) (); 
ргімате: 
суредеб 51а: :тар<іп, Сгеасе5наресаїТЬаск» Са11Ьаскмар; 
риб11с: | 
// возвращает значение +гие, если регистрация прошла успешно 
Боо] ВедіѕТтегѕһаре(іпї ѕһарета, 
Сгеатеѕһареса 11баск Сгеатеғп) ; 
// возвращает значение їгие, если фигура $Варета 
// уже зарегистрирована 
Боо] упгед1тегед4$Наре(1пе $Варета); 
Ѕһаре* Сгеасе5наре(їпс 5Нарегта); 
ргімаєе: 
саТТрасКмар са11баскѕ_; 

}; 

Это общая схема масштабируемой фабрики. Фабрика является масштабируемой, 
поскольку при добавлении нового класса, производного от класса 5Наре, в код не 
нужно вносить никаких изменений. Класс $Нарерастогу разделяет ответственность: 
каждая новая фигура должна зарегистрироваться в фабрике, вызвав функцию Вед1$- 
Ттегѕһаре и передав ей целочисленный идентификатор и указатель на функцию, соз- 
дающую объект. Обычно эта функция состоит всего из одной строки. 


Ѕһаре*& Сгеасеціпе 0 


гетиги пем Ціпе; 

у; 

Реализация класса ціпе также должна зарегистрировать эту функцию в объекте 
класса $Парерасфогу, используемом в приложении. Обычно доступ к этому объекту 
является глобальным. Регистрация выполняется вместе с инициализацией. Связь 
класса і ї пе с фабрикой ЅћареҒастогу устанавливается следующим образом. 

// Модуль реализации класса 11пте 

// создаем безымянное пространство имен, 


// чтобы сделать функцию невидимой из других модулей 
патезрасе 
{ 


Ѕһаре* Сгеатегіпе() 
гетигп пем _іпе; 


// идентификатор класса ііпе 

соп5с 1ПЕ 1ІМЕ = 1; - 

// допустим, что фабрика Тһеѕһареғастогу — 

// фабрика синглтонов(см. главу 6) 

соп5Е Боої гедіѕтегей = 

тһеѕһареғастогу: :Іп5 сапсе 0 .Кедіѕтегѕһаре( 
ЦІМЕ, Сгеагеціпе); 
) 


Благодаря возможностям, предоставленным стандартным ассоциативным массивом 
$14: :тар, класс ѕһареғастогу реализуется легко. По существу, функции-члены клас- 
са $парегастогу переадресуют аргументы функции-члену са11раск. . 


? Это устанавливает связь между фабриками объектов и синглтонами. Действительно, в 
большинстве случаев фабрики являются синглтонами. Ниже в этой главе мы обсудим, как ис- 
пользуются фабрики с синглтонами, описанными в главе 6. 
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роої ЅһареғҒастогу: : Вед15тег$Наре(1птт ѕһарета, 
Сгеатеѕһареса11баск сгеатеғп) 


гетигп са11баск_. іпѕеге( 
Са1ЛбасКкмар: :маТие туре(5Ппарета, сгеатеғп)) .5есопа; 


) 
роої ЅһареҒастогу: :Опгедіѕтегѕһаре(іпїт 5НПарета) 


гетиги са11Баскѕ=_.егаѕе(ѕһарега) == 1; 


Если вы не знакомы с шаблонным классом $14: : мар, предыдущий код нуждается 
в пояснениях. 


• Класс 5%4::тар содержит пары, состояшие из ключей и данных. В нашем 
случае ключами являются нелочисленные идентификаторы фигур, а данные 
состоят из указателя на функцию. Такие пары имеют тип 
ѕта::раіг<сопѕї іпс, Сгеатеѕһареса11баск>. При вызове функции іп5егі 
нужно передавать ей объект этого типа. Поскольку это выражение слишком 
длинное, в классе $14: :мар используется его синоним уа]1ие_туре. В качест- 
ве альтернативы можно использовать также тип $519: : таКе_ра1г. 


• Функция-член 1изегт возвращает другую пару, на этот раз состоящую из ите- 
ратора (ссылающегося на только что вставленный элемент) и булевской пере- 
менной, принимающей значение тгие, если значения в ассоциативном массиве 
до этого момента не было, и Ға1ѕе — в противном случае. 


. Функция-член ега5е возвращаєт количество удаленньх злементов. 


Функция-член Сгеаӯеѕһаре просто извлекает указатель на функцию, соответст- 
вующий полученному идентификатору типа, и вызывает ее. Если возникает ошибка, 
генерируется исключительная ситуация. 


ой Ѕһареғастогу: : Сгеатеѕһаре(іпт е 


Са11Баскмар: : сопѕт_ітегаток і = са11баскѕ_. Ғїіпа(ѕһареха) ; 
1+ (1 == са11Ььаскѕ_. епа 0) 
{ 

// не найден 

тргом $14: : гипїіте еггогС'неизвестньй идентификатор”); 


// вызываем функцию для создания объекта 

гетигп (1->ѕесопа) О; 

) $ 
Посмотрим, что дает нам этот простой класс. Вместо громозлкого оператора ѕміїсћ мы 

получили динамическую схему, требующую, чтобы каждый тип регистрировался в фабри- 

ке. Это распределяет ответственность между классами. Теперь, определяя новый класс, 

производный от класса 5паре, можно просто добавлять файлы, а не модифицировать их. 


8.4. Идентификаторы типов 


Осталась одна проблема — управление идентификаторами типов. По-прежнему 
добавление новых идентификаторов типов требует дисциплинированности и цен- 
трализованного контроля. Добавляя новый класс, программист обязан проверять 
все существующие идентификаторы типов, чтобы новый идентификатор не совпал 
со старыми. Если все же совпадение произошло, второй вызов функции-члена Вед- 
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15теграре с тем же самым денти катором не выполняется, и объект этого типа 
не создается. 

Эту проблему можно решить, выбрав для идентификаторов более мощный тип, 
чем 1пт. В нашем проекте тип іпї вовсе не требуется. Нужны лишь типы, которые 
могут быть ключами ассоциативного массива, т.е. типы, поддерживающиє операторы 
== И <. (Вот почему следует применять ассоциативные массивы, а не векторы.) На- 
пример, идентификаторы типов можно хранить в виде строк, считая, что каждый 
класс представлен своим именем: идентификатором типа |їпе является строка 
"ііпе", типа РОТудоп — строка "РОТудоп" и т.д. Это минимизирует вероятность сов- 
падения идентификаторов, поскольку имена классов уникальны. 

Если вы проводите каникулы, изучая язык С++, предыдущий параграф будет для вас 
предупредительным сигналом. Давайте попробуем применить класс фуре_1пфо! Класс 
5:д::Суре іпРо является частью информации о типах времени выполнения программы 
(Копите Туре шЮппаНоп — КТП), предусмотренных языком С++. Ссылку на класс 
ѕта::туре_іпҒо можно получить, применив оператор їуреіа к типу или выражению. 
Класс $14::туре_1пРо содержит функцию-член пате, возвращаюшую указатель типа 
соп$т сһаг*, ссылающийся на имя типа. Указатель, возвращаемый оператором 
хуреїд(1ї пе) .пате(), ссылается на строку "с\аѕ5 11пе", что и требовалось. 

Проблема состоит в том, что не все компиляторы поддерживают этот оператор. `Спо- 
соб, которым реализована функция їуре_іпҒо: : пате, позволяет применять ее лишь для 
отладки. Нет никакой гарантии, что данная строка действительно представляет собой имя 
класса, и, что еще хуже, нет никакой гарантии, что эта строка является единственной в 
рамках приложения. (Да, пользуясь функцией $14: : туре_1пФо: : пате, вы можете полу- 
чить два класса с одним и тем же именем.) И совсем убийственный аргумент: нет гаран- 
тии, что имя типа постоянно. Никто не может обещать, что оператор 
Туреіа(і іпе) .пате() вернет то же самое имя при повторном выполнении программы. 
Живучесть реализации — важное качество фабрик, а функция ѕта: : туре_1 по: : пате яв- 
ляется неустойчивой. Итак, хотя класс $14: : уре_1пФо на первый взгляд подходит для соз- 
дания фабрик, на самом деле он совершенно неприемлем. 

Вернемся к вопросу об управлении идентификаторами типов. Генерировать иден- 
тификаторы можно с помощью датчика случайных чисел. Этот датчик нужно вызы- 
вать каждый раз, когла создается новый объект. При этом новое значение следует за- 
помнить и больше никогда не изменять.3 Это решение кажется довольно примитив- 
ным, однако вероятность того, что за тысячу лет работы датчик выдаст 
повторяюшееся значение, равно 10729, 

Итак, можно сделать единственный вывод: управление илентификаторами типов не 
входит в компетенцию фабрики объектов. Поскольку язык С++ не может гарантировать 
уникальность и устойчивость идентификатора типов, управление ими выходит за рамки 
языка, и ответственность за его реализацию следует возложить на программиста. 


3 Фабрика СОМ-объектов, разработанная компанией Місгоѕоћ, использует именно такой 
подход. Она содержит алгоритм, генерирующий уникальный 128-битовый идентификатор, на- 
зываемый глобальным уникальным идентификатором (Стіоба! Опідие ]ЧепИйег — СЮ) СОМ- 
объектов. Этот алгоритм основан на уникальности серийного номера сетевой карты или при от- 
сутствии карты даты, времени и других ОНЫХ параметров, характеризующих состояние 
компьютера. 
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Мы описали все компоненты типичной фабрики объектов и привели прототип 
реализации. Перейдем теперь к следующему этапу — от частного к общему. Затем, 
обогатившись знаниями, вернемся к частному. 


8.5. Обобщение 


Перечислим элементы, которые мы упомянули, обсуждая фабрики объектов. Это 
даст нам пишу для размышлений при создании обобщенной фабрики объектов. 


•е Конкретное изделие (сопсгеїе ргодисі). Фабрика производит изделие в виде объекта. 


» Абстрактное изделие (абзігасі ргодисі). Изделие создастся на основе наследова- 
ния базового типа (в нашем примере — класса ѕһаре). Изделие — это объект, 
тип которого принадлежит определенной иерархии. Базовый тип этой иерархии 
представляет собой абстрактное изделие. Фабрика обладает полиморфным по- 
ведением, т.е. она возвращает указатель на абстрактное изделие, не передавая 
знания о типе конкретного изделия. | 


‚ Идентификатор типа изделия (ргодисі ‘буре ійепійег). Это объект, идентифици- 
рующий тип конкретного изделия. Как уже указывалось, идентификатор типа 
необходим для создания изделия, поскольку система типов языка С++ является 
статической. 


• Прозводитель изделия (ргодисі сгеаѓог). Функция или функтор специализируются 
на создании одного, точно заданного типа объектов. Производитель изделия 
моделируется с помощью указателя на функцию. 


Обобщенная фабрика объединяет в себе все эти элементы для создания точно опреде- 
ленного интерфейса, а также задает по умолчанию параметры, характерные для наи- 
более широко распространенных ситуаций. 

На первый взгляд все перечисленные выше элементы можно преобразовать в шаб- 
лонные параметры класса Ғастогу. Однако есть одно исключение: конкретное изде- 
лие не обязано быть известным фабрике. Если бы мы должны были точно указывать 
тип конкретного изделия, то получили бы классы  РЕасбогу для каждого конкретного 
изделия отдельно. Это противоречит нашей цели — изолировать класс Ғасїогу от 
конкретных типов. Тип фабрики должен зависеть только от абстрактного изделия. 

Итак, подведем промежуточный итог в виде следующего шаблона. 

тетр1ате 

< 

с1аѕ5 дбѕтгастРгоаист, 

ТУрепате тдеп+11егтуре, 

Хурепате Ргодис*Сгеатог 
> 

с1555 Еасіогу 


риб'іс: 

боо1 Ведіз5 сег(соп5є т4епе11егТуре& 14, РгойисїСгеатог сгеагог) 
гетигп аззосіаєсіоп5 .іп5еге( 

АѕЅ5ЅОСМар::уа1ие_туре(іа, сгеатог)) .ѕесопа; 
} . 
ђоо1 упгеді5 сегед(соп5 с ІдепсібіегтТуреб 14) 
1 


гетигп аѕѕосіаїтіопѕ_.егаѕе(14) == 1; 
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АБ тгасфргодист* СгеатеоЬјестї (сопѕїт ІдепсіїіегтТурефб 14) 


Турепате А$5осМар: :сопѕї_1їегасог 1 = 
аѕѕосіатіопѕ__Ғіпа (14а); 


1+ (1 != аз5осіасіоп5. .епдО0) 
гехигп (1->5есопа) О; 
обработка ошибок 
а 
хуредеї 57: :тар<ІйептіҒіегтуре, Ађѕтгастргоаист> 


АѕѕосМар; 
А55ОСМар аѕѕосіаїіопѕ_; 


’ 

Осталось только уточнить, что означает “обработка ошибок”. Следует ли генериро- 
вать исключительную ситуацию, если производитель изделия не зарегистрировался в 
фабрике? Возвращать в этом случае нулевой указатель? Прекращать работу програм- 
мы? Динамически загружать ту же самую библиотеку, регистрировать ее на лету и по- 
вторять выполнение операции? Выбор зависит от конкретной: ситуации. В каждой из 
них может оказаться разумным одно из перечисленных решений. 

Наша обобщенная фабрика должна давать’ пользователю возможность настраивать 
ее на любое из перечисленных выше действий и предусматривать разумное поведение 
по умолчанию. Следовательно, код, предназначенный для обработки ошибок, должен 
быть выделен из функции-члена Сгеаїеобјесї в отдельную стратегию Еасбогувггог 
(глава 1). Эта стратегия состоит только из одной функции ОпипКпомптуре, а класс 
Ғастогу предоставляет этой функции шанс (и соответствующую информацию) для 
принятия любого разумного решения. 

Стратегия Еастогуеггог очень проста. Она представляет собой шаблонный класс с 
двумя параметрами: тдепт1Е1егтуре и АБзтгастРгодист. Если класс РастогуЕг- 
гогітр! представляет собой реализацию стратегии Ғасіогуєггог, должно применять- 
ся следующее выражение. 

вастогуєггогітрі«тдепсіїіегтуре, Аб5тгасергодист> Ғастогуєггогітр1; 

ІдепсібіегТуре 14; 

АБѕїгастргоаисе* рРгодисі = РаскогуЕггогттр1 .опупКпомптуре (149) ; 

Класс Ғастогу использует класс БасбогуЕггогітр? в качестве спасательного 
круга: если класс Сгеасебобіесі не может найти ассоциацию в своем внутреннем 
ассоциативном массиве, он использует функцию-член ҒастогуЕг- 
гогітрі«ІдепсібіегТуре, АБзтгасЕргодист>: :Опупкпомптуре для извлечения 
указателя на абстрактное изделие. Если функция ОпупКпомптуре генерирует исключи- 
тельную ситуацию, она передается за пределы класса Растогу. В противном случае 
функция Сгеатеобјесїт просто возврашает результат выполнения функции Опіп- 
Кпомптуре 

Попробуем закодировать эти дополнения и изменения (выделенные в тексте про- 
граммы полужирным шрифтом). 

сетр1ате 

< 

с1аѕ5 АбѕїТгастрРгойистї, 
хурепате таепїі#іегтуре, 


Турепате РгойисїСгеатог, 
тетр1аїте<турепате, с1аѕ5> 
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сТаз55 ҒастогуЕггогРо1ісу 


> 
с]а$$ Расфогу 
руб] 1с ҒастогуєггогРо1їсу<Ійепіі#Ғіегтуре, АБзтгасеРгодист> 


риБ11с: р 
АБѕТгасіргойисїі* СгеатеоЬјесї (сопѕт ІдепсіРіегТуреб 14) 
{ 
Турепаме Аѕ50сМар: : сопѕ1_1№егаог і = 
аѕѕосіатіоп_. Ріпасїа) ; 
18 (1 != аѕѕосіатіопѕ_.епа()) 


гехигп (і->ѕесопа) (); 


гесигп Опупкпомптуре (іа) ; 
} 


ргімате: А 
... остальные функции и данные остаются неизменными 
}; 


По умолчанию реализация стратегии ғастогуєггог генерирует исключительную ситуа- 
цию. Класс исключительной ситуации должен отличаться ото всех других типов, чтобы 
клиентский код мог распознать его и принять соответствующие решения. Кроме того, этот 
класс должен быть производным от одного из стандартных классов исключительных си- 
туаций, чтобы клиентский код мог перехватывать все виды ошибок в одном блоке сатсћ. 
Стратегия реҒаи1ҒастогуЕггог содержит вложенный класс исключительной ситуации (с 
именем Ехсер+іоп)ќ, производный от класса 514: : ехёерсіоп. 


тетр1асе <с1аѕ55 Ійепїі#іегтуре, с1аѕ5 РгодисіТуре» 
с1аѕ5 реҒаи1тҒастогуЕггог 


риБ1їс: 
с1аѕ55 Ехсерсїоп : риБ1іс 5+4: :ехсертіоп 


{ 
риБ11с: 
Ехсерїіоп(сопѕт Ідепті#ҒіегТуре& ипкпоипІа) 
ипкпомпій (ипкпомпіа) 
1 


) 


мігтиа1 сопзт сһаг* мпас ОО 

гетигп "Фабрике передается неизвестный тип."; 
соп5ї т4епе11егтуре сестаО 

гетигп ипкпоимтпта_; 


у 
ргімате: 
ІФепсівіегТуре ипкпомпій ; 


рготестеа: 
Ѕтатісргойисттуре* ОпипкпомпТуре (соп5 є Ідепсібіегтуреб 14) 
1 


хбгом еЕхХСсерсіоп(14); 


) 
}; 


4 Давать этому классу другое имя (например ЕассогуЕхсерііоп) нет никакой необходи- 
мости, поскольку этот тип определен внутри шаблонного класса реЁаи1тҒастогуЕггог. 
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Другие, более сложные реализации стратегии РасфкогуЕггог могут искать иденти- 
фикатор типа и возвращать указатель на подходящий объект, возвращать нулевой ука- 
затель (если генерировать исключительную ситуацию нежелательно), генерировать 
объект исключительной ситуации или прекращать выполнение программы. Уточнять 
поведение класса можно с помощью новых реализаций стратегии РасфогуЕггог, пе- 
редавая их в качестве четвертого аргумента класса Ғасїогу. 


8.6. Мелкие детали 


На самом деле реализация класса Ғасёогу в библиотеке ГоК! не использует класс 
з 4: : тар. Вместо него она применяет класс Аѕѕ0сУестог, оптимизированный на ред- 
кие вставки и часто повторяющиеся операции поиска элементов. Эта ситуация харак- 
терна для класса Еастогу. Класс Аззос\Уестог подробно описан в главе 11. 

В первоначальном варианте класса Ғастогу ассоциативный массив считался на- 
страиваемым, поскольку был шаблонным параметром. Однако часто класс Аззос\ес- 
тог полностью удовлетворяет всем требованиям класса Ғасїогу. Кроме того, исполь- 
зование стандартных контейнеров в качестве шаблонных шаблонных параметров не 
соответствует стандарту языка. Вот почему программисты, занимающиеся реализаци- 
ей стандартных контейнеров, могут добавлять новые шаблонные аргументы, задавая 
их значения по умолчанию. 

Сосредоточим теперь ‘свое внимание на шаблонном параметре Ргодис®Сгеатог. Во- 
первых, он должен обладать функциональным поведением (допускать применение опера- 
тора ©) и не иметь аргументов) и возвращать указатель, который можно преобразовывать в 
тип АбѕтгассРгоаист*. В конкретной реализации, показанной выше, объект класса Рго- 
диссСгеасог был просто указателем на функцию. Этого достаточно, если нужно создавать 
объекты, вызывая оператор пем, как это бывает в большинстве случаев. Следовательно, в 
качестве типа РгоаистСгеатог, задаваемого по умолчанию, можно выбрать следующий: 


АБѕтгастРгойисїі* (=) 0 


Этот тип выглядит весьма странно, так как не имеет имени. Если после звездочки 
указать имя, поместив его внутри скобок, тип станет указателем на функцию, не полу- 
чающую никаких параметров и возвращающую указатель на класс АБ сгасеРГОодисс. 
Если все это вас по-прежнему удивляет, обратитесь к главе 5, в которой обсуждаются 
указатели на функцию. 

Кстати, в этой главе описан очень интересный шаблонный параметр, который 
можно передавать классу Ғастогу в качестве параметра РгойисїСгеатсог, а именно: 
Еипстог<АБѕтгастрРгоацст*>. Этот параметр обеспечивает отличную гибкость: можно 
создавать объекты, вызывая простую функцию, функцию-член или функтор, а также 
связывать с ними соответствующие параметры. Код, обеспечивающий связь между 
ними, содержится в классе ғипсіог. 

Объявление шаблонного класса Ғастогу выглядит следующим образом. 

тетр1ате 

< 

сТа55 Абѕтгастргоаист, 
сТа55 ІдепсіїїегТуре, 
сТа55 РГгодистсгеатог = Абѕтгассргоаистс* (*) О, 
тетр1ате<їтурепате, с1аѕ5> 
сТїа55 ғастогуєггогро1ісу = реҒацітғастогуєггог 
> 
сТаз55 Ғастогу; 


Теперь класс гастогу полностью готов. 
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8.7. Фабрика клонирования 


Несмотря на то что генетические фабрики, клонирующие универсальных сол- 
дат, — идея страшноватенькая, клонировать объекты языка С++ — занятие совер- 
шенно безвредное и даже полезное. Цель клонирования объектов, которую мы рас- 
смотрим, несколько отличается от того, что мы имели в виду раньше: мы больше не 
должны создавать объекты с самого начала. У нас есть указатель на полиморфный 
объект, и мы хотели бы создать точную копию этого объекта. Поскольку тип поли- 
морфного объекта точно не известен, мы на самом деле не знаем, какой именно объ- 
ект создать. В этом и заключается проблема. 

Поскольку оригинал у нас под рукой, можно применить классический полимор- 
физм. Следовательно, при клонировании объекта нужно объявить в базовом классе 
виртуальную функцию-член СТопе и заместить ее в производном классе. Рассмотрим 
клонирование объектов на примере иерархии геометрических фигур. 


Сс1аз$ ѕһаре 


риб]11с: 
у1гЕца] 5Наре* С1опе() соп${ = 0; 


$}; 
сТа55 ціпе : риБЬ1іс Ѕһаре 


риБ1іс: 
уігеџа] ііпе* С1опе() соп5і 


гесигп пем гіпе(*тећіѕ); 


} 


}; 

Функция-член ііпе: :С1опе не возвращает указатель на класс 5Наре, поскольку 
мы применили свойства языка С++, называемые ковариантными типами возвращае- 
мых значений (сомагіапі геќигп ќуреѕ). Благодаря этому замещенная виртуальная функ- 
ция может возвращать указатель на производный класс, а не на базовый. Теперь, сле- 
дуя идиоме, мы должны реализовать аналогичную функцию СТопе в каждом классе, 
который добавляется в иерархию. Эти функции имеют одно и то же содержание: соз- 
дается объект класса Ро1ідоп, возвращается указатель пем РоЛудопС*ћі5) и т.д. 

Эта идиома работает, но имеет ряд недостатков. 


• Если базовый класс изначально не предназначался для клонирования (в нем не 
объявлялась виртуальная функция, эквивалентная функции СТопе) и модифи- 
кации, то эту идиому применять нельзя. Такая ситуация возникает, например, 
когда вы пишете приложение, используя в качестве базовых классы из какой- 
нибудь библиотеки. 


• Даже если все классы можно модифицировать, эта идиома требует особой осто- 
рожности. Отсутствие реализации функции СТопе в производных классах ком- 
пилятор не замечает, что может привести в непредсказуемым последствиям при 
выполнении программы. 


Первый недостаток очевиден, поэтому перейдем к обсужлению второго. Прелста- 
вим себе, что, создавая класс боїтей! іпе, производный от класса і іме, мы забыли 
заместить функцию роттейі і пе: : СТопе. Кроме того, допустим, что у нас есть указа- 
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тель на объект класса Ѕһаре, который на самом деле ссылается на объект класса рот- 
теа іпе, и мы вызываем из этого объекта функцию С1опе. 

Ѕһаре* рѕһаре; 

Ѕһаре* ррир1ісатеѕһаре є рѕһаре->С1опес) ; 

Вызывается функция 1 іпе: :С1опе, возвращающая объект класса (1пе. Это очень не- 
приятно, поскольку мы предполагали, что указатель ррир1ісаёеѕћаре имеет тот же 
динамический тип, что и указатель р5Варе. Оказывается, это совсем не так, что может 
вызвать массу проблем — от вывода неожиданных типов до краха приложения. 

К сожалению, надежных средств, позволяющих компенсировать второй недоста- 
ток, не сушествует. На языке С++ нельзя сказать: “Я определяю эту функцию и хочу, 
чтобы она замещалась во всех производных классах”. Если вы не хотите неприятно- 
стей, придется определить замещаемую функцию СТопе в каждом классе. 

Если указанную идиому немного усложнить, можно организовать приемлемую 
проверку типа во время выполнения программы. Сделаем функцию СТопе открытой и 
невиртуальной. Внутри класса она будет вызывать закрытую виртуальную функцию ро- 
СТопе, гарантируя эквивалентность динамических типов. Соответствующий код про- 
ще, чем его объяснение. 


с1аѕ5 Ѕһаре 


риЬ1їс: 
Ѕһаре* СТопе() сопѕт // Невиртуальная функция 


// переадресовываем вызов функции росС1опе 

Ѕһаре* рСТопе = рос1опе() ; 

// проверяем эквивалентность типов 

// Сэтот тест может быть сложнее, чем макрос аѕѕегт) 
аѕѕегї(туреіа(*рс1опе) == туре? 4(*тН1$)); 

гетигп рсС1опе; 


} 
ргімате: 

мігтиа? Ѕһаре* росТопе() сопѕі = 0; // Закрытая функция 
$; 


Единственным недостатком этого подхода является тот факт, что теперь нельзя 
использовать ковариантные типы возвращаемых значений. 

Все наследники класса Ѕһаре должны замещать функцию рос1опе, оставляя ее за- 
крытой, чтобы клиенты не могли вызвать ее. Функция СТопе должна оставаться в 
стороне. Клиенты используют только функцию СТопе, осуществляющую проверку ти- 
пов во время выполнения программы. Очевидно, что и здесь мы не гарантированы от 
появления программистских ошибок, например, замещения функции СЛопе или объ- 
явления функции роС1опе открытой. 

Не забывайте, что если все классы, входящие в иерархию, изменить невозможно 
(такая иерархия называется закрытой), и если они не предназначены для клонирова- 
ния, эту идиому реализовать все равно не удастся. Такая ситуация встречается до- 
вольно часто, поэтому нам следует поискать альтернативу. 

На помощь может прийти специальная фабрика объектов. Она свободна от недос- 
татков, указанных выше, но немного снижает производительность программы — вме- 
сто виртуального вызова выполняется поиск по карте и вызов через указатель на 
функцию. Поскольку количество классов приложения на. самом деле никогда не бы- 
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вает очень большим (ведь они создаются людьми, не так ли?), карта обычно невелика, 
и задержка становится незначительной. 

Основная идея состоит в том, что идентификатор типа и изделие имеют одинако- 
вый тип. На вход фабрики поступает дублируемый объект в виде идентификатора ти- 
па, а на выход возвращается новый объект, представляющий собой точную копию 
этого идентификатора. ‘Точнее говоря, их тип не совсем одинаков: тип Ійепїі- 

-Ғіегтуре из фабрики клонирования — это указатель на объект класса АБ- 
ѕтгастргойист. На самом деле фабрика получает на вход указатель на клонируемый 
объект, а возврашает — указатель на клон. 

А какие ключи хранятся в ассоциативном массиве? Они не могут быть указателями 
на объекты класса Аз тгастРгодист, поскольку количество элементов ассоциативного 
массива не зависит от количества объектов в программе. Каждый элемент этого мас- 
сива должен соответствовать отдельному типу клонируемого объекта, что вновь при- 
водит нас к стандартному классу 514: :туре_1пРо. Идентификатор типа, передавае- 
мый фабрике клонирования при необходимости создать новый объект, отличается от 
идентификатора типа, хранящегося в ассоциативном массиве. Это не позволяет нам 
повторно использовать написанный ранее код. Кроме того, производителю изделия 
теперь нужен указатель на клонируемый объект. В фабрике, которую мы разработали 
ранее, параметры были не нужны. 

Подведем итоги. Фабрика клонирования получает на вход указатель на объект 
класса АђѕТгастРгодйист. Она применяет к этому объекту оператор туреїа и получает 
ссылку на объект класса $14; : туре _јіпҒо. Затем она ищет этот объект в закрытом ас- 
социативном массиве. (Функция-член Бебоге класса $14: : туре_1пРо устанавливает 
отношение порядка между объектами этого типа. Это позволяет использовать ассо- 
циативный массив и осуществлять быстрый поиск.) Если элемент не найден, вызыва- 
ется производитель изделия, которому передается указатель на объект класса АБ- 
ѕЅтгастргойист, введенный пользователем. 

Поскольку у нас уже есть шаблонный класс Ғастогу, реализация класса С1опеҒас- 
тогу упрощается. (Вы можете найти ее в библиотеке Го.) Класс С1опеғастогу не- 
много отличается от класса Еастогу. 


» Класс СТоперастогу использует класс Туретпфо, а не $*4: : *уре_1пФо. Класс 
ТуреІпҒо, рассмотренный в главе 2, представляет собой оболочку указателя на 
объект класса $14: :туре_1п®о. В нем определены инициализация, оператор 
присваивания, операторы == и <, необходимые для работы с ассоциативным 
массивом. Первый оператор переадресовывает вызов оператору класса 
514: : суре _іпҒо; :орегатог==, а второй — функции 519: : туре_1пРо: : БеФоге. 

• В классе больше нет типа Ійепєі#іегтуре, поскольку идентификатор типа яв- 
ляется неявным. 

• Шаблонньй параметр РгодистСгеатог по умолчанию задает тип 
АБѕТгастргоаист“ (*) САБ тгасеРгодист*). 

® Класс ІатоРгоЯистМмар теперь заменен классом 
Аѕѕосместог<ТуреїпҒо, РгоаистСгеатог>. 

Класс С1опеҒастогу имеет следующий вид. 


тетрТ1ате 
< 
с1аѕ5 АБѕїтгастРгоайист, 
с1аѕ5 РгодисеСгеахог = 
АБ тгасеРГгодист* (*) (АрѕтгастрРгоаист*), 
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тетрТате<турепате, с1а55> . 
С1аз$ ЕассогуЕггогРоїісу = рефаи1тЕастогеггог 


> 
с1аѕ5 СПоперасбогу 


1 
рибТіс: 
АБѕтгастргойист* СгеатеоЬјест (сопѕт АБзтгасеРгодист* тойе1); 
Боо] Ћедіѕтег(сопѕт ТуретпҒо&, 
РгодиссСгеабсог сгеатог); 
Боо1 упгедіѕтег(сопѕє ТуретпҒо&); 
ргімате: 
ТуреаеҒ д$зос\уестог<Туретп®о, РгойистСгеатог> 
ІатоРгоёисттар; 
таторгойистмар аѕѕосіаїіопѕ_; 


, 
Шаблонный класс С1опеғастоғу представляет собой полное решение задачи клони- 
рования объектов, принадлежащих закрытой иерархии классов (т.е. иерархии, которую 
невозможно модифицировать). Своей простотой и эффективностью этот класс обязан 
концепциям, описанным в предыдущих разделах, а также информации о типах, предос- 
тавляемой операторами ®уреїа и классом 514: : уре_1пфо. Если бы механизма ВТТІ не 
сушествовало, фабрику клонирования было намного труднее реализовать. 


8.8. Использование фабрики объектов в сочетании 
с другими обобщенными компонентами 


В главе 6 был разработан вспомогательный класс 5іпд1есопно1аег. Поскольку 
фабрики имеют глобальную природу, естественно использовать класс гастогу вместе 
с классом $1п91етопно1 дег. Их легко объединить с помощью оператора суреде?. 


туредеї Ѕіпд1етопно1аег<Ғастоғу<ѕһаре, 514: :51гіпд> > 5Нарерастогу; 


Разумеется, для уточнения проектных решений в классы 5іпд1есопної1дег и Еас- 
согу можно добавлять аргументы, но все это происходит в одном месте. Следователь- 
но, теперь можно собрать группу важных решений в одном месте и применить класс 
ЅһареғҒастогу. С помощью простого определения типа, указанного выше, можно вы- 
бирать способ функционирования фабрики и синглтона. Единственная строка кода 
отдает компилятору приказание сгенерировать соответствующий код, аналогично то- 
му, как вызов функции с разными аргументами определяет разные пути ее выполне- 
ния. Поскольку в нашем случае все это происходит во время компиляции, основной 
упор переносится на проектные решения, а не на выполнение программы. Разумеет- 
ся, это не может не влиять на выполнение программы, однако это влияние имеет 
косвенный характер. Когда вы пищете “обычный” код, вы определяете, что будет 
происходить во время выполнения программы. Когда вы пишете определение типа, 
подобное приведенному выше, вы указываете, что должно произойти во время ком- 
пиляции программы — это можно назвать вызовом функций, генерирующих код. 

Как указывалось в начале этой главы, болыной интерес вызывает комбинация 
класса Растогу с классом ғипсїог. 


хуредеї 51іпд1етопно1аег 


< 
Ғастсогу 
< 
Ѕһаре, ѕ7а::51гіпд, Рипстог<5Наре*> 
> 
> 
Ѕһареғастогу; 
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Использование класса Ғипсіог обеспечивает большую гибкость при создании объек- 
тов. Теперь новые объекты класса 5Варе и его потомков можно создавать всевозмож- 
ными способами, регистрируя в фабрике разные функторы. 


8.9. Резюме 


Фабрики объектов — важный компонент программ, использующих полиморфизм. 
Они позволяют создавать объекты, когда их тип либо совсем недоступен, либо несо- 
вместим с конструкциями языка. 

В основном фабрики объектов применяются в объектно-ориентированных прило- 

жениях и библиотеках, а также в различных схемах управления живучестью объектов 
и потоками. Схема управления потоками детально проанализирована на конкретном 
примере. По существу, она сводится к распределению типов между разными файлами 
реализации, обеспечивая высокую модульность программы. Несмотря на то что фаб- 
рика остается основным средством создания объектов, она не обязана собирать ин- 
формацию обо всех статических типах, входящих в иерархию. Вместо этого, она за- 
ставляет каждый тип зарегистрироваться на фабрике. В этом заключается принципи- 
альная разница между “правильным” и “неправильным” подходом. 
° Информацию о типе во время выполнения программы на языке С++ передавать 
трудно. Эта особенность носит принципиальный характер для всего семейства языков, 
которому принадлежит язык С++, поэтому приходится применять вместо типа его 
идентификатор. Идентификаторы типов тесно связаны с вызываемыми сущностями, 
создающими объекты (глава 5). Для определения этих ограничений реализована кон- 
кретная фабрика объектов, обобщенная в виде шаблонного класса. 

В заключении рассмотрены фабрики клонирования, позволяющие создавать дуб- 
ликаты полиморфных объектов. 


8.10. Краткий обзор шаблонного класса Еасіогу 
» Объявление класса гастогу имеет следующий вид. 


тетрТате 
< 

сТаз5 АБ5 єгассРГОИСТ, 

с1аѕ5 Ідепсібїегтуре, 

сТа55 РгодисіСгеаїог = Аз СгассРГОЧИСІ"? (*)(), 

тетр1асе<ёурепате, с1аѕѕ> 

сТа55 ғастогуєггогРо1ісу = реҒаи1тғастогуєггог 

> 


сТа55 Ғасїіогу; 


• Класс дбѕтгастргойис?ї является базовым классом иерархии, для которой соз- 
дается фабрика объектов. 


® Класс Ідепсібіегтуре представляет тип, входящий в иерархию. Он должен иметь 
отношение порядка, позволяющее хранить его в объекте класса 514: : тар. Обычно в 
качестве идентификаторов типа используются строки и целые числа. 


• Класс Ргойис+Сгеатог представляет собой вызываемую сущность, создаюшую 
объект. Этот класс должен поддерживать оператор (), не иметь параметров и 
возвращать указатель на объекты класса Аб5 ТГастРГОдист. Объект класса Рго- 
аистсгеатог всегда регистрируется вместе с идентификатором типа. 
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В классе Ғассогу реализуются следующие примитивы. 
роої ведіз ег(соп5 є ІйепїіїҒіегтуре&, Ргойисссгеатог сгеатог); 


Эта функция регистрирует производитель изделия вместе с идентификатором 
типа. Если регистрация прошла успешно, она возвращает значение їгие, в про- 
тивном случае возвращается значение Ға1ѕе (если производитель изделия с тем 
же идентификатором типа уже зарегистрирован ранее). 


роої упдегі5сегед(соп5 є т4епе1Р1егтуре& 14); 


Зта функция аннулирует регистрацию идентификатора заданного типа. Если зтот 
идентификатор был зарегистрирован ранее, функция возвращает значение Єгие, 


АЮрѕїгасіРгойисє* СгеасеоЬјесї (сопѕї ІдепїіҒіегтуре& 14); 


Эта функция выполняет поиск идентификатора типа во внутреннем ассоциа- 
тивном массиве. Если идентификатор найден, она вызывает соответствующий 
производитель объектов данного типа и возвращает результат его работы. Если 
идентификатор не найден, возвращается результат работы функции растогуЕг- 
гогРо1їсу<Іаепїї#їегтуре; АБѕтгастргойист»> : : ОпупКпомптуре. По умолча- 
нию реализация класса ЕастогуЕггогРОТісу генерирует исключительную си- 
туацию вложенного типа Ехсерї1іоп. 


8.11. Краткий обзор шаблонного класса СІопеҒасїогу 


236 


Объявление класса СТопеЕасбогу имеет следующий вид. 


тетрТате 
< 
с1аѕѕ АђѕТгастргойистї, 
сТа55 Ргойисїсгеатог = 
Арѕтгастргоаист* (*) (сопѕї АрѕТгастргойист*), 
тетрї1ате<турепате, с1аѕ5> 
с1аѕ5 ҒастогуЕггогРо1ісу = реҒаџ1 тғастогуЕггог 
> 
сТа55 СТоперастогу; 


Класс Абѕ®гастргоаист является базовым классом иерархии, для которой соз- 
дается фабрика клонирования. 


Класс Ргойистсгеатог представляет собой вызываемую сущность, создающую дуб- 
ликат объекта, передаваемого как параметр, и возвращающую указатель на клон. 


В классе С1опеғастогу реализуются следующие примитивы. 
роої Ћеаіѕтег(сопѕт ТуреїІпҒо&, РгодиссСгеасог сгеагог); 


Эта функция регистрирует производитель изделия вместе с типом ТуреїІпҒо 
(что позволяет неявно вызывать конструктор копирования класса 
$14: : Суре_1пКо). Если регистрация прошла успешно, она возвращает значение 
ские, в противном случае возвращается значение Ға1ѕе. 


Боо1 упдегіз5тегед(соп5 с Туреїпіов туре1пфо); 


Зта функция аннулируєт регистрацию производителя обьектов заданного типа. 
Если этот тип был зарегистрирован ранее, функция возвращает значение гие. 


Арѕтгастргоаист* сСгеатеоюјест (сопѕт АБбзтгасеРГОЧисЕ* тоде1); 
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Эта функция выполняет поиск динамического типа объекта тодеї во внутрен- 

нем ассоциативном массиве. Обнаружив тип, она вызывает соответствующий 

производитель объектов данного типа и возвращает результат его работы. Если 

тип не найден, возвращается результат работы функции Расбсогуєггогрої- 
" ісу«Огдегедтуретпіо, АБ5 сгасєРГОЇИСТ»: :ОпупКпомптуре. 
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ШАБЛОН АВЗТВАСТ ЕАСТОВУ 


В этой главе обсуждается обобщенная реализация шаблона проектирования АБ- 
тгасе Еассогу (Сатта єї а!., 1995). Абстрактная фабрика — это интерфейс для соз- 
дания семейства связанных или взаимозависимых объектов. 

Абстрактные фабрики могут быть важными архитектурными компонентами, по- 
скольку они гарантируют, что в системе создаются правильные конкретные объекты. 
Если вы не хотите, чтобы кнопка гипКувиЕтоп появлялась в диалоговом окне Сопуеп- 
хіопаїріаїод, используйте шаблон проектирования АБзтгаст Еастогу, гарантирую- 
ший, что эта кнопка появляется только в окне Еийпкуріаїод. Для этого нужно про- 
контролировать лишь небольшую часть кода, а остальная часть приложения будет ра- 
ботать с абстрактными типами 01а1од и Виттоп. 

В главе рассматриваются следующие вопросы. 


® Область применения шаблона проектирования Абзтгаст Еасбогу. 
» Определение и реализация компонентов шаблона Ађѕїгаст Еасіогу. 


• Использование обобщенных функциональных возможностей шаблона Ађѕтгаст 
Ғастогу, предоставленных библиотекой Т.о, и их расширение. 


9.1. Архитектурная роль шаблона Арбітасі Ғасїогу 


Представьте себе, что вы разрабатываете компьютерную игру “найти и уничто- 
жить” наподобие роот или Оцаке. 

Вы хотите соблазнить потенциального покупателя своей игрой, поэтому преду- 
сматриваете легкий уровень. На этом уровне вражеские солдаты абсолютно тупые, 
монстры представляют собой желеобразную массу, а супермонстры настроены крайне 
дружелюбно. 

Более крутых игроков вы соблазняете уровнем повышенной сложности. На этом 
уровне вражеские солдаты совершают три выстрела в секунду и владеют приемами ка- 
рате, монстры коварны и вероломны, а супермонстры встречаются постоянно. 

Возможная модель этого ужасного мира, населенного врагами и монстрами, может 
содержать базовый класс Епету и производные от него интерфейсы $о141ег, мопзтег 
и 5ирегМоп5 сег, Затем на основе этих интерфейсов для реализации легкого уровня 
игры создаются производные классы 5111уѕо1дїег, 5111умопѕїег и $1] ]лузирегмоп- 
тег. В заключение для уровня повышенной сложности реализуются классы ва45о1 - 
Тег, ваймопѕтег и вайѕирегмопѕтег. В результате возникает иерархия классов, 
представленная на рис. 9.1. 


ЗирегМоп ег 


ЗШубирегМоп${ег ВайЅирегМопѕіег 


ЗШубо!ег Ва4бо ег 


Мопвїег 


ЅШуМопвќег ВааМопеїег 


Рис. 9.1. Иерархия классов для игры с двумя уровнями сложности 


Стоит напомнить, что в вашей игре конкретизации классов Вад5о1дїег и 5111у- 
Мопѕтег никогла не “встречаются” друг с другом. Это не имело бы смысла. Игрок на 
легком уровне имеет дело с классами 5111у5014їег, 5111умопѕтег и 5111уѕирегоп- 
ѕтег, а на уровне повышенной сложности — с классами Вад5о191ег, ваймопѕтег и 
Вайѕирегмопѕтег. 

Две категории типов формируют два семейства. Во время игры всегда используют- 
ся объекты лишь одного конкретного семейства, а комбинации объектов, принадле- 
жащих разным семействам, никогда не возникают. 

Было бы прекрасно, если бы это соответствие выполнялось автоматически. В про- 
тивном случае, если программист не проявил необходимой осторожности, новичок, 
развлекающийся с объектами класса 5111у5014аїег, может неожиданно встретиться в 
темном углу с объектом класса ВаЧМоп5 тег. В этом случае обиженные игроки могут 
потребовать от вас возврата денег. 

Поскольку лучше проявлять осторожность заранее, функции, предназначенные для 
создания объектов, задействованных в игре, следует объединить в одном интерфейсе. 
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сТа55 АБ5 СгассЕПетуРвассогу 


руБ11с: 
мігсуаї 5о014діег? маке5о1даїегО 0; 
уігтиа1 Мопѕтег* Макемопѕтег() = 0; 
мігсуаї ѕирегмопѕсег* Макеѕирегмопѕтег() = 


; 
Тогда для каждого уровня сложности создается конкретная фабрика врагов, соз- 
дающая объекты в соответствии с заданной стратегией игры. 


с1аѕ5 Еаѕуіеуе1ЕпетуҒастоғу : рибТіс АБ5 С гастЕпетуғастогу 


1 

риб'їс: 

$0141ег* макеѕо1аїег; 

{ гетигп пем 5111уѕо1аїег; } 

Моп5 сег" макемоп5 сег () 

{ гехигп пем 5111умМопѕтег; } 
зирегмоп5 сег? макеѕирегмопѕтег О 
{ гетигп пем $11Тубирегмопз${ег; ) 


}; 
с1аѕѕ ріенагаіеме1ЕпетуҒастогу : риБ1іс АБѕтгастЕпемуғастогу 


{ 

руБ11с: 
$0141ег* маке5оТаїегО 
{ гехигп пем Вааѕо1аіег; } 
Моп5сегх такемопѕ сег О 
{ гехигп пем Ваамопѕтег; } 
Зцрегмоп5 сег» МаКебирегмоп${ег() 
{ гесигп пем вадбзирегмоп5 сег; ) 


}; 
В заключение мы инициализируем указатель на объект класса АБ5 сгассЕпетувас- 
хогу соответствующего конкретного класса. 


сТа55 Сатедрр 


уоіа 5еТескіеуе1 О 


1Ғ (пользователь выбрал легкий уровень игры) 


{ 
рҒассогу_ = пем Еаѕуі еме1ЕпетуҒастогу; 
е1ѕе 
{ | 
реассогу. = пем Оіенагагеуе1Епетуғастогу; 
} 
0; 
ргімате: 


// используем указатель рЕасфогу_ для создания врагов 
АбѕТгастЕпетуҒастогу* рЕастогу_; 
$; | 
Преимущества этого подхода заключаются в том, что он сохраняет все детали создания 
и сопоставления врагов внутри двух реализаций класса АђѕтгастҒастогу. Поскольку при- 
ложение использует указатель рғастогу_ исключительно для ссылки на объект производи- 
теля, соответствие объектов уровню игры обеспечивается автоматически. 
Шаблон проектирования Абѕёгасі Ғассогу предписывает, чтобы все функции, 
предназначенные для создания объектов, были сосредоточены в отдельном интерфей- 
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се. Затем программист должен выполнить реализацию этого интерфейса отдельно для 
каждого семейства создаваемых объектов. 

Типы, анонсированные абстрактным фабричным интерфейсом (5о141ег, Мопзтег и 
Ѕирегмопѕтег), называются абстрактными изделиями (абзігасі ргодисі). Типы, которые 
фактически создаются (5$111уЗо191ег, Вайѕо1аїег, 5111 умопзтег и т.д.), называются кон- 
кретными изделиями (сопстеїе ргодис!). Эти термины уже встречались в главе 8. 

Основной недостаток шаблона Ађѕїгасї Ғастогу заключается в том, что базовый 
класс фабрики (в нашем примере АбѕїгасїЕпетуҒасїогу) должен владеть информа- 
цией о каждом создаваемом абстрактном изделии. Кроме того, по крайней мере в 
только что описанной реализации, каждый конкретный фабричный класс зависит от 
конкретного изделия, которое он создает. 

С помощью приемов, описанных в главе 8, можно понизить степень этой зависи- 
мости. В той главе мы создавали конкретные объекты, не зная ничего об их типах. 
Единственным доступным источником информации были идентификаторы типов 
(например, целые числа или строки). 

Однако, чем больше мы снижаем степень зависимости между классами, тем мень- 
ше становится объем информации о типах, следовательно, значительно снижается 
степень типовой безопасности приложения. Это еще один пример классической ди- 
леммы, возникающей в языке С++: высокая степень типовой безопасности или сла- 
бая взаимосвязь между классами. 

Как это часто бывает, правильное решение можно найти с помошью компромисса. 
В каждом конкретном приложении следует искать свою золотую середину. Общее 
правило таково: используйте статическую модель, если можете, и динамическую мо- 
дель, если вынуждены. 

Обобщенная реализация шаблона АБзтгаст ғастогу, описанная в следующих раз- 
делах, обладает интересным свойством, позволяющим снизить степень статической 
зависимости между классами без снижения степени типовой безопасности. 


9.2. Обобщенный интерфейс шаблона Аббігасі Еасіогу 


Как указывалось в главе 3, функциональные возможности класса Туре115$1 позволяют 
реализовать обобщенный шаблон Аб5 гасі Ғастогу. В этом разделе показано, как опре- 
деляется обобщенный интерфейс АБзтгастрастогу с помощью списков типов. , 

Пример, описанный з предыдущем разделе, представляет собой типичное приме- 
нение шаблона проектирования Ађѕїгасї Ғасїогу. Его использование сводится к 
следующему. 


• Определяется абстрактный класс (класс абстрактной фабрики), содержащий од- 
ну чисто виртуальную функцию для каждого типа изделий. Виртуальная функ- 
ция, соответствующая типу т, обычно возвращает указатель типа т*. Она назы- 
вается Сгеагет, макет или как-то еще. 


• Определяется одна или несколько конкретных фабрик, реализующих интер- 
фейс, определенный абстрактной фабрикой. Реализуется каждая из функций- 
членов, создающих новый объект производного типа с помощью оператора пем. 

Все это выглядит довольно просто, но при возрастании количества изделий, созда- 

ваемых абстрактной фабрикой, программа становится все более ненадежной. Более 
того, в любой момент программист может внедрить в программу новую реализацию, 
которая использует другой механизм распределения памяти, или прототип объекта. 
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В этой ситуации на помощь приходит шаблон АБ5тгаст гастогу при условии, что 
он достаточно гибок и позволяет легко реализовать новый механизм распределения ` 
памяти и передачи аргументов конструктору. 

Напомним, что шаблонный класс бепѕсаттегніегагсһу, описанный в главе 3, 
конкретизирует базовый шаблон, предоставленный пользователем, для каждого типа, 
приведенного в списке типов. По своей структуре полученная в результате конкрети- 
зация класса бепѕсаїтегніегагсһу наследует все конкретизации шаблона, предостав- 
ленного пользователем. Иными словами, если есть шаблон Шпії и список типов 
ТЕ1$1, то класс бепѕсаттебніегагсһу<тііѕї, Цпіс» является наследником класса 
упіє«т» для каждого типа Т, указанного в списке Ті151. 

Класс Сбепѕсаїтегніегагсһу может оказаться очень полезным для определения 
интерфейса абстрактной фабрики — программисту достаточно определить интерфейс, 
который способен создавать объекты определенного типа, а затем применить этот ин- 
терфейс к нескольким типам с помощью класса беп5саїтегніегагсНу. 

Интерфейс, способный создавать объекты обобщенного класса Т, выглядит сле- 
дующим образом. 


тетр1ате <с1а$$ т> 
с1аѕѕ АБзтгастрастогуупйте 


{ 

риЬ1іс: 
уігтца) Т" росгеате(туре2Туре<т> = 0); 
уігтсуа) «АрзхСгассРассогуупієО {} 


}; 
Этот небольшой шаблон выглядит вполне прилично — виртуальный конструктор и 
ничего больше!, — но зачем здесь класс Туре2туре? Как указывалось в главе 2, класс 


Туре2туре — это простой шаблон, единственное предназначение которого — обеспе- 
чить однозначный выбор перегруженных функций. Ладно, но где тут перегруженные 
функции? Ведь в классе АБ сгаскЕастогуупі є определяется только одна функция ро- 
Сгеате. Однако одной и той же иерархии классов могут принадлежать разные конкре- 
тизации класса АБзтгастрастогууй1т. Класс Туре2туре<т> позволяет избежать неод- 
нозначности выбора разных вариантов перегруженной функции росгеате. 

Обобщенный интерфейс АБ5$тгастгастогу использует класс бепзсастегніегагспу 
в сочетании с классом АбѕТгасїіҒасїогуупіт. 

тетр1ате 

< 


с1аѕ5 Т1, 
хетрТасе «сТа55» с1аѕѕ Упії = АрѕігасіҒастогушпіт 


> 
с1аѕ55 АрѕігасїіҒасїогу : рибТіс бепѕсаїітегніегагсһу<ті1і51, Упіс» 
риБ11с: А 

Турейе# тііѕі Ргодисіі1ѕ+; 

хетрТасе <с1аѕѕ т> Т* Сгеате() 


упіс <Т>& ипіс = 015; 
гетигп ипіє. росгеате (Туре2туре<т> 0); 


}; 


1! Виртуальные конструкторы подробно обсуждались в главе 4. 
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Вот тут-то на арене появляется класс Туре2туре, уточняющий, что функция ро- 
Сгеате вызывается функцией Сгеате. Проанализируем следующий фрагмент кода. 
// Код приложения 
Хуредеї АБѕтгастҒассогу 
< 
ТУРЕТТЬТ_3($0191ег, мопѕтег, ѕирегмопѕтег) 


> 
АБѕїігастЕпетуғастогу; 


В главе 3 было показано, что шаблонный класс Ађѕ®гасёҒастогу генерирует ие- 
рархию классов, показанную на рис. 9.2. Класс Арѕтгас®Епетуғассогу является по-` 
томком классов АБ; сгасфРастогуип1 є«5014їег», АбѕігастҒасёогуупії<Мопѕтег> и 
АБз сгастЕпету/п1 +<бирегмоп$ег>. В каждом из них определяется чисто. виртуальная 
функция-член Сгеате, так что класс АБ сгассЕпетувастогу обладает тремя перегружен- 
ными функциями Сгеаге. Короче говоря, класс Аб5 сгассЕпетуЕасбогу практически эк- 
вивалентен абстрактному классу с тем же именем, определенному в предыдущем разделе. 


СепЅсайегНіегагсћу СегбсайегНіегагсһћу 
<5ЅирегМопѕїег,АБѕїгасїҒасїогу0пії> «МиїТуре, Аб5ігасіКасіогудпії» 


СепбсабіегНіегагспу СепбсанегНіегагспу 
«Моп5іег, Аб5ігасіРасіогудпії» <ТҮРЕЦЅТ 1(5ирегМопѕїег),АБѕїгасіҒас?огу0пії> 


СепЅсайегНіегагсћу бепбсанегНіегагспу 
«5оідіег, Аб5ігасіРасіогуупії <ТҮРЕЦЅТ 2(Мопѕќег, 5ирегМоп5іег),Ар5ігасіРасіогудпіи» 


АБвігасіЕпетувасіогу 


Рис. 9.2. Иерархия классов, генерируемая классом АйзігастГастогу 
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Шаблонная функция-член Сгеате из класса АБзтгасерастогу играет роль диспет- 
чера, направляющего запрос на создание объекта соответствующему базовому классу. 

АБ5сгастЕпетурастогу*“ р = 

Мопѕтег“* родге = р- о сгватехнойзкегьО; 

Автоматически генерируемая версия класса обладает одним важным преимущест- 
вом — класс АБзтгастепетурастогу имеет высокий уровень модульности (егапиіагігу). 
Программист может автоматически конвертировать ссылку на объект класса АБзтгас- 
ТЕпетуҒастогу в ссылку на объект класса дђѕтгасіҒастогу<ѕо14іег>, Абѕтгасїғас- 
тогу«Моп5Ттег» или АБзтгасеРастогу<5ирегмопзтег>. Таким образом, различным 
частям приложения можно передавать лишь небольшие разделы фабрики. Например, 
допустим, что некий модуль (5игргі5е5 .срр) должен создавать только объекты класса 
зирегмопз тег. Этому модулю можно передавать только указатели или ссылки на объ- 
екты класса АрѕТгастҒастогу<ѕирегмопѕтег>, так что модуль 5игргі5е5.срр не свя- 
зан ни с классом 5014їег, ни с классом Моп$тег. 

Используя модульность класса дрѕтгастғастогу, можно сократить количество 
связей, задействованных в шаблоне проектирования АБзтгаст Еастогу. Это не сни- 
зит степень безопасности интерфейса абстрактной фабрики, поскольку модульным 
является только интерфейс, а не реализация класса. 

Итак, перед нами встает проблема реализации интерфейса. Второе важное пре- 
имущество автоматически сгенерированной версии класса АБ5тгастЕпетуРастогу за- 
ключается в том, что его реализация также генерируется автоматически. 


9.3. Реализация класса Аб5ігасіЕасіогу 


Определив интерфейс, перейдем к реализации класса, стремясь сделать это как 
можно проше. 

Поскольку интерфейс использует списки типов, естественно построить обобшен- 
ную реализацию класса АђѕтгастҒастогу с помошью списков типов конкретных из- 
делий. С практической точки зрения реализация класса, соответствующего легкому 
уровню игры, должна выглядеть следующим образом. 

// Код приложения 


туредеї Сопсгетевастогу 
« 
// Абстрактная фабрика, подлежащая реализации 
АбѕтгастЕпетуғастогу, 
// Стратегия создания объектов 
// (например, с помощью оператора пем) 
Ормемгастогууитт, 
// конкретные классы, создаваемые данной фабрикой 
ТҮРЕШІЅТ__3 (5111уѕо1аіег, 5111умопѕтег, 5111у5ирегмоп5 сег) 


> 
Еаѕуі еуе1ЕпетуҒастогу; 


Три аргумента гипотетического (пока) шаблонного класса СопсгетеҒастогу со- 
держат достаточно информации, чтобы полностью реализовать фабрику. 


• Класс АбѕтгастЕпетуғастогу описывает интерфейс абстрактной фабрики, под- 
лежащей реализации, и неявно задает список изделий. 


• Класс ОрмемҒастогуупіт представляет собой стратегию, ОПЕЛЬ каким 
образом осуществляется фактическое создание объектов. 
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» Список типов содержит набор классов, создаваемых фабрикой. Каждый кон- 
кретный тип, указанный в списке, соответствует абстрактному типу с тем же 
индексом в списке типов класса АБ5 {гасегастогу. Например, класс $111 умоп- 
5 сег (индекс 1) представляет собой конкретную разновидность класса Мопзтег, 
имеющую тот же индекс в определении класса АБ тгастЕпетурастогу. 


Описав класс СопѕгесеҒастогу, попробуем его реализовать. Немного поразмыс- 
лив, легко прийти к выводу, что количество замещений чисто виртуальных функций 
должно совпадать с количеством определений класса. (В противном случае мы не 
смогли бы конкретизировать класс СопсгеїеҒасїогу.) Следовательно, класс Соп- 
сгетерастогу должен быть производным от класса ОрмемЕастогуцпії, отвечающего 
за реализацию функции росгеате. 

Здесь большую помощь может оказать шаблонный класс СепТіпеагніегагспу 
(глава 3), поскольку в нем предусмотрены все детали генерации нужных нам реализаций. 

Класс АБзсгастЕпетургастогу должен быть корнем иерархии. Все реализации 
функции росСгеате и окончательный класс Еаѕуі еме1ЕпепуҒассогу должны быть 
производными от него. В каждой реализации класса ОрмемҒастогуцпії должна заме- 
щаться одна из трех чисто виртуальных функций роСгеате, определенных в классе 
АБЗ гастЕпетугастогу. 

Определим класс ОрмемРастогуїпії. Очевидно, класс ОрМемЕастогудпіс — это 
шаблонный класс, получающий тип создаваемого объекта в качестве шаблонного па- 
раметра. Кроме того, класс СбепііпеагніегагсПу требует, чтобы класс ОрмемҒасто- 
гуупіє получал дополнительный шаблонный параметр и был его потомком. (Класс 
Сеп іпеагніегагсһћу использует второй аргумент для генерации линейной (ѕїгіпе- 
ѕһареа) иерархии наследования, изображенной на рис. 3.6.) 


сетрЛ1ате <с1аѕ5 СопсгегеРгодисі, с1аѕ5 Вазе> 
с1аѕ5 ОрмемЕассогуйпіс : риБ1їс Ваѕе 


Турейе? турепате Ваѕе: : Ргоаисті_151 ВаѕеРгойисті15ї1; 
рготестеа: 

Турейе? турепате вазеРгодисті 151: :Таї1 Ргойисті 151; 
риЬ11с: 

Туредеї турепате ВаѕеРгойисїі 151: :Неад АБѕТгастРгоаисї; 

СопсгетеРгодисі" роСгеате (Туре2туре<АБѕтгастРгоаистї>) 


гесигп пем Сопсгетергодист; 
} 

$; 

Чтобы определить какос абстрактное изделие следует создать, класс 
ОрмемҒастїогуупі є должен выполнять только одно вычисление типа. 

Каждая конкретизация класса ОрмемЕастогуфпії является компонентом некоей 
“пищевой” цепи. Каждая конкретизация класса ОрмемҒастогуџпітї “откусывает” го- 
лову списка изделий, замешая соответствующую функцию боСгеате и передавая 
“безголовый” список Ргоаисті151 вниз по иерархии классов. Таким образом, конкре- 
тизация класса Ормемкастогуупі є, находящаяся на вершине иерархии (сразу за клас- 
сом АрѕТгасіЕпетуҒастогу), реализует функцию росСгеате(Туре2Туре<ѕо14іег>), а 
конкретизация, находящаяся на дне иерархии, реализует функцию оосге- 
ате(туре2Туре<ѕирегмопѕтег>). 

Итак, попробуем разобраться, почему класс ОрмемҒастогуупії занимает такое вы- 
сокое положение в иерархии. Во-первых, класс ОрмемҒастогуупіт импортирует тип 
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Ргоаисї 151 из базового класса и присваивает ему новое имя Ваѕергойисїі 151. 
(Просмотрев определение класса дђѕтгасїғасїогу, легко понять, что он на самом де- 
ле экспортирует тип Ргойисїі151.) Абстрактное изделие, реализованное классом 
Ормемғастогуупіт, представляет собой голову списка ВазеРгодистіїі5 г в соответст- 
вии с определением класса Абѕтгастргойист. В заключение класс Ормемкастогуцпі є 
реэкспортирует класс Вазергодисть1$т::Та11 в качестве типа РГОДИСТЕЛ$ т. Остав- 
шаяся часть списка передается вниз по иерархии. 

Обратите внимание на то, что функция Ормемгастогууп1 т: :ОоСгеате не возвра- 
щает указатель на объект класса АБ гасеРгодис*, как это делает ее настоящий про- 
тотип. Вместо этого она возвращает указатель на объект класса Сопсгетергодист. 
Можно ли это по-прежнему квалифицировать как реализацию чисто виртуальной 
функции? Да, благодаря ковариантным типам возвращаемых значений (сомагіапі геиги 
їуреѕ). Язык С++ позволяет возвращать указатель на объект производного класса. В 
этом есть глубокий смысл. Благодаря этим типам программист либо знает точный тип 
конкретной фабрики, получая максимум информации, либо знает только ее базовый 
тип, получая меньший объем информации. 

Класс сопсгетергастогу должен генерировать иерархию, используя класс беп- 
| і пеагніегагспу. Его реализация вполне очевидна. 

тетр1ате 

< 

сТа55 АБѕїгасіғаст, 
хетрТаге «с1а55, сТа55» с1а$$ Сгеасог = ОРМемғастогуупіт; 


сТа55 Ті151 = турепате АБѕТгастғасі: :Ргодисті іѕт 
> 
сТа55 Сопсгетегастогу 
рчЬ1іс Сеп і пеагніегагсбу« 
Турепате Ті: Вемегѕе<ті151>: :Веѕи1ї, Сгеатог, Ађѕїгастғасі> 


хуредеї турепате АЬѕігастғасї: : Ргойисїі 51 Ргодиссіі5 Є; 
хуредеї тіьіѕт сопсгесеРгоаисїі_ 151; 


з 
Иерархия классов, генерируемая классом Сепііпеагніегагсһу для класса 
сопсгетеЕастогу, показана на рис. 9.3. 

Здесь скрывается одна маленькая хитрость: класс Сопсгетеғастогу должен пере- 
ворачивать список конкретных изделий, передавая его классу Сепі іпеагніегагсну. 
Зачем? Для этого нужно вернуться к рис. 3.6, на котором показано, как класс беп- 
Е1пеагН1егагсну генерирует иерархию. Этот класс передает типы из списка типов в 
шаблонный аргумент уи1е снизу вверх. Первый элемент списка типов передается 
конкретизации класса Юпіє, находящейся на дне иерархии классов. Однако класс 
ормемкассогудпіс реализует перегрузку функции роСгеате сверху вниз. Следова- 
тельно, класс СопсгетеҒастогу должен переворачивать список ТЕ1$1, используя ста- 
тический алгоритм ті: : Вемегзе (глава 3), и только после этого передавать его классу 
Сепііпеагніегагсћу. 

Если вы все еще считаете классы АђѕтгасїҒассогу и Сопсгетерастогу сложными 
и запутанными, потерпите. Так кажется потому, что классы небрежно обращаются со 
списками типов. Списки типов представляют собой новое понятие, и, чтобы привык- 
нуть к нему, требуется время. Если вы будете считать списки типов подобием 
“черного ящика” — “списки типов по отношению к типам играют ту же роль, что и 
обычные списки по отношению к значениям”, — реализация классов сразу станет 
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понятнее. Если уж вы на самом деле решили использовать списки типов, то ваши воз- 
можности станут поистине неограниченными. Не верите? Читайте дальше. 


АрѕігасїЕпетуҒасіогу 
Д 
ОрМемҒасіогу0пї<511уЅо!діег, АбѕігасіЕпегтуҒасѓќогу> 
А 
СеппеагНіегагсһу<ТҮРЕЦЅТ 1(5уЅо!аіег), ОрМемҒасіогуупӣ,АбѕігасїЕпетуҒасіогу> 
А 
ОрМемСгеаїог<511уМопѕїег, беппеагНіегагсћу<ТҮРЕШ5Т 1(511уЅоІаіег), ОрМем'Растогуйтії, АбѕітасїЕпетуҒасіогу>> 
Д 
СбепііпеагНіегагсћу<ТҮРЕЦШ5Т2(511уМопѕїег, 511уЅо!аіег), ОрМ№емСтеаїог,АбѕігасїЕпетуҒасїогу> 
Д 


ОрМемРасіогудпі« ЗЙубирегМоп$!ег, бепіпеагНіегагсһу 


<ТҮРЕЦШЅТ2(5уМопѕїег, ЗНубо ег), ОрМемСтеаїог,АбѕітасїЕпетуҒасїогу>> 
Д 


СепціпеагНіегагсћу<ТҮРЕШЅТ 3(51у5ирегМопзїег, 51уМопѕїег, 511уЅо!аіег), ОрМ№емҒасіогуупӣ,АбѕігасіЕпетуғҒасіогу> 
Д 
ЕаѕуіехеіЕпе туҒасїогу 


Рис. 9.3. Иерархия классов, генерируемая для класса ЕазуЁеуе!ЕпетуРасюгу 


9.4. Реализация шаблона АБбѕїгасї Касіогу на основе 
прототипов 


Шаблон проектирования Ргототуре (Сатта еї а, 1995) описывает метод созда- 
ния объектов, начиная с ирототипа, представляющего собой некий архетип. Новые 
объекты получаются путем клонирования прототипа. Суть этого способа заключается 
в том, что функция клонирования является виртуальной. 

В главе 8 детально обсуждалась важная проблема, возникающая при создании по- 
лиморфных объектов. Эта проблема называется дилеммой виртуального конструктора: 
при создании объекта с нуля нужно знать тип создаваемого объекта, хотя полимор- 
физм предполагает отсутствие точной информации о типе. 
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Шаблон проектирования Ргототуре избегает этой дилеммы, используя прототип 
объекта. Имея прототип, мы можем использовать преимущества виртуальных функ- 
ций. Дилемма виртуального конструктора по отношению к самому прототипу остается 
нерешенной, но теперь она носит намного более локальный характер. 

В описанном выше примере подход, основанный на применении прототипов при 
создании врагов, задействованных в компьютерной игре, вынуждает использовать ука- 
‚затели на объекты базовых классов 5014їег, мопзтег и Ѕирегмопѕтег. В этом случае 
код может выглядеть примерно так.? 


с1аѕѕ Сатедрр 


мої а 5е]есеьеуе] О 


{ 

1 (пользователь выбрал уровень повышенной сложности) 

{ | 
рготоѕо1аїег_. геѕет (пем Вад5оїдїег); 
ргосомоп5 сег... геѕеї (пем Ваймопѕтег) ; 
рготоѕирегмопѕтег_. геѕеї (пем Вайѕирегмопѕтег) ; 

е1ѕе 
ргоёоѕо1діег_. геѕеє (пем 5111уѕо1аіег) ; 
рготомопѕтег_. геѕет (пем 51 11умоѕптег) ; 
рготоѕирегмМопѕтег_. геѕеї (пем 51 11уѕирегмоѕпїёег) ; 

} 


Ѕо1аіег* макеѕо1аіег() 


// в каждом вражеском классе определяется 
// виртуальная функция С1опе 
гесигп рРгосо5о1даїег -»СТопе(О; 


Классы Макемоп5сег и МаКебирегмоп$ {ег определяются аналогично 


ргімате: 
// используем эти прототипы для создания врагов 
айсо ріг«501дїег» ргоёоѕоТЯїег_; 
айсо рег«Моп5 сег» ргосомоп5 сег ; 
айсо рег«5ирегмоп5єег» ргоёоѕирегмМопѕтТег_; 


} 

Разумеется, в реальном коде лучше было бы разделить интерфейс и реализацию. Ос- 
новная идея заключается в том, чтобы класс батедрр хранил указатели на базовые 
вражеские классы — прототипы. Класс сатедрр использует эти прототипы для созда- 
ния вражеских объектов, применяя к ним виртуальную функцию С1опе. 

Реализация шаблона Ађѕтгасїт Ғастогу, основанная на применении прототипов, 
может хранить указатель на каждый тип изделия и использовать для создания новых 
изделий функцию СТопе. 

В классе СопсгетеҒастогу, использующем прототип, больше нет необходимости 
предусматривать конкретные типы. В нашем примере для создания объектов классов 
5111уѕо1атег и Вад5оТтаїег нужно лишь передать фабрике соответствующие прото- 
типы. Статический тип прототипа — базовый класс 5014їег. Фабрика не обязана ни- 


2 Учтите, этот код неверно обрабатывает исключительные ситуации. Исправьте его само- 
стоятельно. 
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чего знать о конкретных типах объектов. Она просто вызывает виртуальную функ- 
цию-член СТопе из соответствующего прототипа. Это ослабляет зависимость конкрет- 
ных фабрик от конкретных типов. 
Однако, для того чтобы механизм класса Сепі і пеаѓніегагсһу работал правильно, 
нужен список типов. Напомним, как выглядит объявление класса Сопсгетерастогу. 
хетрТате 
< 
сТа55 АБзтгасткаст, 
тетрЛате «сТа55, с1аѕѕ5> с1аѕ5 Сгеатог, 
сТа55 ТЕ15т 
> 
с1аѕѕ Сопсгетеғастогу; 


Класс тиіѕї — это список конкретных изделий. В классе Еаѕу1еуе1Епетуғастїогу 
класс Ті. 15 был известен под именем 

ТҮРЕШІЅТ_3 (5111уѕо1аіег, 5111умопѕтег, 5111уѕирегмопѕтег) 

При использовании шаблона проектирования Раїтегп класс Ті151 становится неуме- 
стным. Однако класс ті15ї по-прежнему необходим классу бепі іпеагніегагсһу для 
генерации отдельного класса для каждого изделия, указанного в списке абстрактных 
изделий. Что делать? 

В этой ситуации естественно передать список абстрактных изделий классу Соп- 
сгетеғастогу в качестве аргумента тііѕтї. Теперь класс бепі іпеагніегагсһу сможет 
генерировать правильное количество классов, а изменять реализацию класса Соп- 
сгесекассогу не понадобится. 

Объявление класса Сопсгетеғасїогу принимает следующий вид. 

тетр1ате 

< 

сТа55 Абрѕтїгастғаст, 
Тепр1ате «сТа55, сТа55» с1аѕѕ Сгеатог, 
с1аѕ5 Т.1517 = турепаме Арѕтгастғаст: : Ргойистііѕт 

> 

с1аѕ5 Сопсгетеғастогу; 

Напомним, что определение класса АђѕїгасїҒасї, приведенное в разделе 9.3, содер- 
жит внутренний класс Ргойисїі1 51. 

Перейдем теперь к реализации шаблонного класса РготосуреҒастогуупіт, содер- 
жащего прототип и вызываюшего функцию С1опе. Его реализация намного проше, 
чем реализация класса ОрмемРастогуупі є, поскольку вместо двух списков типов класс 
 Ргототуреғастогуџпіт работает только с одним списком абстрактных изделий. 


тетрТате «сіа55 СопсгетеРгодисі, сіа55 Ваѕе> 
сТа55 Ргототурегастогуиптт : рибТіс вазе 


ТуредеҒ турепаме Ва5е::Ргодиссі.і5ї Вазергодист11$т; 
рготестеа: 

ТуредеҒ турепаме Ваѕе: : Ргойисїі151 Таї1Ргоаисї1151; 
рибб'їс: 

туредеї турепате Ваз5е::Ргодисі|ї58::Неад АбѕТгасїіРГгойисі; 

РготоТуреғастогуцпіт Сдбрѕтгастргоаист“ р = 0); 

б рргототуре_ (р) 


Ғгіепа моїд робетргототуре(сопѕт Ргототуреғастогуџпітё те, 
АБѕтгасїРгойисїт*& рРгототуре) 


рргототуре = ме.рРгототуре_; 
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Ғгіепа уоіа роб5есРгоОСоСуре(Ргососуревасбсогуупі єв те, 
Абѕт гастРгойцст* робі) 
{ 


пе. рргототуре_=роЬј ; 


тетр1ате <с1аѕ5 » 
уоіа СбетРгосотуре (Абѕ сгасеРгодисс*& р) 


гесигп ОбосесРгосогуре("єНіз, р); 


тетр1ате «сТа55 УЮ» 
усій Ѕеїргоёотуре(0у* робі) 
{ 


ОоЅетРгосоїуре (*6ћі5, робі); 


} 
АБ5ЕгастРгодисе* роСгеате (Туре? Туре<Аб $ т гасЕРгодис+>) 


аѕѕеге (рргоїотуре_) ; 
гесигп рРгототуре -»СТопе(); 


ргімате: 
АБѕігасіРгоаисе* рРгобобуре ; 


; 
Шаблонный класс Рготоїуреғастогуупіт основан на некоторых предположениях. 
Во-первых, он не владеет своим прототипом. Можно потребовать, чтобы функция 
Ѕесргототуре удаляла старый прототип перед его переприсваиванием. Во-вторых, 
класс РготоїтуреҒастогуџпії использует функцию СТопе, предположительно клони- 
рующую объект. В конкретном приложении можно использовать другое имя, руково- 
дствуясь собственными вкусами или требованиями, предъявляемыми библиотекой. 
Если нужно настроить фабрику, основанную на применении прототипов, достаточно 
написать шаблонный класс, аналогичный классу Рготоуреғастогуцпіє. Для этого можно 
применить механизм наследования, сделав класс Ргоќобуреғастогуцпі є базовым и заме- 
щая соответствующие функции. Допустим, что мы решили реализовать функцию боСге- 
ате так, чтобы она возвращала нулевой указатель, если указатель на прототип равен нулю. 
сетрТ1ате «сТа55 АБзтгасеРгодисе, с1аѕѕ Вазе> 


сТа55 МуРастогуупії 
рир1іс Ргососуревастогуйцпі є«Аб5 єгасіРгойисї, Ваѕе> 


риЬ1іс: 
// Реализуем функцию росгеате так, чтобы она допускала 
// нулевой указатель на прототип 
АБбѕтгастргоаист* росгеате(Туре2Туре<дбрѕтгастсргойист>) 


гесигп рргототуре_ ? рРгосотуре -»СТопе0 : 0; 


}; 
Вернемся к нашей компьютерной игре. Для того чтобы определить конкретную 
фабрику, нам нужно написать следующий код приложения. 


// код приложения 
суреде? Сопсгетегастогу 


< 
АБ5 сгастЕПетуРасбогу, 
Ргототуреғастогуупіт 
> 
Епетурастогу; 
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Итак, дуэт классов АБбѕїігасїҒасіогу/СопсгетеҒасёогу предоставляет нам сле- 
дующие возможности. 


® Легко определять фабрики с помощью списков типов. 


• Поскольку класс АђѕїгасїҒасїогу наследует каждый из своих компонентов, 
его интерфейс обладает высокой модульностью. Отдельные указатели или 
ссылки на подобъекты класса АЕйпіє«Т» можно передавать разным модулям, 
уменьшая общую взаимозависимость классов. 


+ Для реализации класса дбѕїгастғасіогу можно применить класс Сопсгете- 
Ғастогу, используя стратегию, диктуюшую метод создания объектов. Статиче- 
ски связанным стратегиям создания объектов (таким как класс Орм№емҒас?о- 
гуупі тї, использующий оператор пем) нужно передавать список конкретных из- 
делий, создаваемых фабрикой. 


® Наиболее распространенной стратегией создания объектов является шаблон 
проектирования Ргототуре. Эту стратегию можно легко реализовать в классе 
Сопсгетерастогу с помощью щаблонного класса РгототуреҒастогуџпітї. 


Попробуйте получить все перечисленные выше преимущества, реализовав шаблон 
проектирования Ађѕїгасї Еастогу вручную. 


9.5. Резюме 


Шаблон проектирования Аб5 гасі Расфогу — интерфейс для создания семейства 
связанных или взаимозависимых полиморфных объектов. Используя этот шаблон, 
можно разделить классы реализации на разные непересекающиеся семейства. 

Интерфейс обобщенной абстрактной фабрики можно реализовать с помошью спи- 
сков типов и шаблонных стратегий. Списки типов предусматривают списки изделий 
(конкретных и абстрактных) и шаблонные стратегии. 

Шаблонный класс АбѕёгасїҒасіогу представляет собой скелет для определения 
абстрактных фабрик в сочетании с шаблонным классом Ағџпіт. Класс АБзтгастрас- 
Тогу использует класс сепѕсаттегніегагсћһу (глава 3) для генерирования модульного 
интерфейса, наследующего класс АРУп1{<Т> для каждого абстрактного изделия Т, ука- 
занного в списке типов. Эта структура позволяет уменьшить взаимозависимость клас- 
сов, передавая в различные части приложения только отдельные модули фабрик. 

Шаблон Сопсгетегасфогу позволяет реализовать интерфейс класса АђѕїгасїҒас- 
Тогу. Класс Сопсгетерасфогу использует для создания объектов стратегию Ғасїо- 
гуци1т и класс Сепі іпеагніегагсНу (глава 3). В библиотеке 101 предусмотрены две 
реализации стратегии Расісогуйпії: класс ОпмемҒастогуупії, создающий объекты с 
помощью оператора пем, и класс РгоіотуреҒастогуупітї, создающий объекты с по- 
мошью клонирования прототипов. 


9.6. Краткий обзор классов АБб5ігасіЕасіогу 
и СопсгаеРастогу 
е Объявление класса АБ фгас%Расфогу выглядит следующим образом. 


тетр1ате 
< 
с1а$$ Тііѕ+, 
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ТетрЛате <с1аѕѕ> сТа55 Опії = АБЗ єгаскРастогуцпії 
» 
с1аѕ5 Абрѕтгасіғас+іогу; 


Здесь класс ТЕЛ 517 является списком типов, состоящим из абстрактных изделий, 
создаваемых фабрикой, а класс Чпії — это шаблон, определяющий интерфейс 
каждого типа из списка Ті15ї. Например, приведенное ниже выражение опре- 
деляет абстрактную фабрику, способную клонировать объекты классов 501 41ег, 
Мопѕ сег и 5ирегмопз ег. 


Хуредевб Аб5 сгастРастогу«ТІРЕЦІЗТ, 3(5014їег, Моп5іег, 
зирегмопзтег> дрѕтгастЕпептуғастогу ; 


• Класс АБѕегастҒасоғгуупіё<т> определяет интерфейс, состоящий из чисто 
виртуальных функций, имеющих сигнатуру т* роСгеате(Туре2Туре<Туре>). 
Обычно функцию рбоСгеате не нужно вызывать явно. Вместо нее вызывается 
функция Ађѕтгастғастогу: : Сгеате. 


• Класс АбѕїігасіҒасёогу содержит шаблонную функцию Сгеаќе, которую мож- 
но конкретизировать для любого из типов абстрактных изделий. 


Ар5 с гастЕПетураскогу *рғасіогу = . 
$о141ег *рѕо1Яіег = рғастогу- сна ОЕ 
• Для реализации интерфейса, определенного классом АБ гастрастогу, библио- 
тека го содержит шаблонный класс СопсгетеҒасїогу. 


тетр1ате 

< 
с1аѕѕ Ађѕтгастғас+, 
сетр1а+е «сТа55, с1аѕѕ> с1аѕѕ гасфогууп1е = ОрмемҒасіогуупі, 
с1аѕ5 Т151 = Абѕгасіғасі: : Ргоаисі 151 

> 

с1аѕ5 Сопсгетеғастогу; 


Здесь класс Абѕїгастғастї представляет собой конкретизацию класса Абѕїгасї- 
ғастогу, подлежащего реализации. Класс ғастогуупіт является реализацией 
стратегии Еасбогуйпі 8, а класс т.151 — это список конкретных изделий. 


• Класс Ғасіогуџпіє имеет доступ к абстрактному и конкретному изделиям, 
подлежащим созданию. В библиотеке [окі определены две стратегии Сгеаїог: 
классы Ормемғасёогуупіт (раздел 9.3) и РгоготуреҒастогуџпіт (раздел 9.4). 
Их можно использовать для настраиваемой реализации стратегии ғастогипі +. 


• Класс Ормемғас®огуџпії использует для создания объектов оператор пем. 
Применяя этот класс, нужно передавать список типов, состоящий из типов 
конкретных изделий, в качестве третьего шаблонного параметра класса Соп- 
сгетеғасїогу. 


суредеї Сопсгетеғастогу 
< 
АрѕігастЕпетуҒасїогу, 
Ормемғастогуцпіт, 
ТҮРЕТЅТ_3(5111уѕо1аіег, 5111умоп5 сег, 
5111уз5ирегмоп5 сег) 


> 
Еаѕуі еуе1ЕпетуЕастогу; 


Глава 9. Шаблон АБѕїтасї Расіогу 253 


254 


Класс Ргототуреғастогуупіт хранит указатели на типы абстрактных изделий и 
создает новые объекты, вызывая функцию-член СТопе с соответствующими па- 
раметрами. Для этого в классе РгототуреҒастогуупії для каждого абстракт- 
ного изделия т нужно определить отдельную виртуальную функцию С1опе, воз- 
вращающую указатель типа т“ и дублирующую объект. 


При использовании класса РгототуреҒастогуупіт в сочетании с классом Соп- 
сгетерастогу третий шаблонный аргумент класса Сопсгетерастогу не нужен. 


ТурейеҒ Сопсгесевастогу 


< 
АБѕтгастепемтуғастогу, 
Ргототсуреғастогуипі є 
> 
ЕпепуРгодист; 
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ШАБЛОН МІЅІТОВ 


В этой главе обсуждаются обобщенные компоненты, использующие шаблон проекти- 
рования У1$1тог (Сатта е а1., 1995). Это мощный шаблон проектирования, изменяю- 
щий зависимость между проектными решениями, принятыми при разработке класса. 

Шаблон Уіз5ітог (Инспектор) обеспечивает удивительную гибкость: в иерархию 
классов можно добавлять виртуальные функции, не прибегая к повторной компиля- 
ции ни этих функций, ни существующих клиентских кодов. Однако эта гибкость дос- 
тигается за счет определенных жертв: в иерархию теперь невозможно добавить новый 
терминальный класс (Ісаї с]аѕѕ), не повторив компиляцию всей иерархии и ее клиен- 
тов. Следовательно, область применения шаблона \1$1%ог ограничивается только 
очень устойчивыми иерархиями (в которые редко добавляются новые классы) и про- 
граммами, в которые часто приходится добавлять новые виртуальные функции. 

Шаблон уї5ітог противоречит программистской интуиции. Следовательно, для 
его успешного применения нужны тщательная реализация и строгая дисциплина. В 
главе описывается обобщенная реализация шаблона У1$1тог, оставляющая приклад- 
ному программисту очень мало работы. 

В главе обсуждаются следующие темы. 


• Принцип работы шаблона уіѕітог. 


• Когда следует применять шаблон \151%ог и, что не менее важно, когда его 
применять не следует. 


• Базовая реализация инспектора (предложенная группой Сор). 
• Как устранить некоторые недостатки базовой реализации шаблона Уі $1тог. 


• Как реализовать решения, касающиеся реализации шаблона Уіѕіїог, в виде 
библиотеки. 


• Мощные обобшенные компоненты, облегчающие реализацию инспекторов. 


10.1. Основы шаблона Мі5іїог 


Рассмотрим иерархию классов, которую мы хотим наделить новыми функциональ- 
ными возможностями. Для этого в нее можно добавлять либо новые классы, либо но- 
вые виртуальные функции-члены. 

Добавить новые классы легко. Можно применить механизм наследования к тер- 
минальному классу и реализовать необходимые виртуальные функции. Для этого не 
нужно изменять или компилировать вновь существующие классы. Их коды остаются 
неизменными и готовы к повторному использованию. 


В противоположность этому, добавить новую виртуальную функцию трудно. Для 
того чтобы полиморфно манипулировать объектами (с помошью указателей на объек- 
ты базового класса), виртуальную функцию-член нужно добавить не только в базовый 
класс, но и, возможно, во многие другие классы, входящие в иерархию. Это — основ- 
ная операция. Она модифицирует базовый класс, от которого зависит вся иерархия и 
ее клиенты. В результате все придется повторно компилировать. 

Короче говоря, с точки зрения зависимостей между классами новые классы добав- 
лять легко, а новые виртуальные функции-члены — трудно. 

Однако допустим, что у нас есть иерархия, в которую редко добавляются новые 
классы и в то же время часто добавляются новые виртуальные функции-члены. В этой 
ситуации возможность легко добавлять новые классы представляет собой ненужное 
преимущество. Вот тут-то и пригодится шаблон уіѕітог. Этот шаблон предоставляет 
программисту именно ту функциональную возможность, в которой он в данный мо- 
мент нуждается, позволяя легко вставлять в иерархию новые виртуальные функции- 
члены, одновременно затрудняя вставку новых классов. За это придется заплатить 
всего-навсего лишним виртуальным вызовом. 

Шаблон М1$1тог лучше всего проявляет свои возможности, когда операции на 
объектами не связаны между собой. Парадигма “состояние и операции” для каждого 
класса становится не совсем уместной. В данной ситуации лучше придерживаться 
принципа отделения типов от операций. Имеет смысл хранить разные реализации од- 
ной операции вместе, а не распределять их по иерархии классов 

Допустим, что мы разрабатываем текстовый редактор. Элементы документа, такие как 
абзацы и графические изображения, представляются в виде классов, производных от од- 
ного базового класса, скажем, БосЕ1етепт. Документ — это структурированный набор ука- 
зателей на объекты класса росЕЛетепї. Программисту нужна возможность перемещаться 
по этой структуре и выполнять операции, например, проверку орфографии, переформати- 
рование и вычисление статистических показателей. В идеале следовало бы реализовывать 
эти операции, добавив новый код без модификации существующей программы. Более то- 
го, программу было бы легче сопровождать, если бы весь код, связанный, скажем, с вы- 
числением статистических показателей, хранился в одном месте. 

К статистическим показателям могут относиться общее количество символов, зна- 
чащих символов, слов и рисунков. Все это естественным образом можно поместить в 
класс росѕтат5. 


с1аѕ5 босбтат$ 


ипѕідпеа іп, 
сһагѕ_, 
попв1апксћагѕ_, 
мога$_, 
ітаде5 ; 
риБ11с: 
\014 АЧЧСПаг$ (ипѕідпеа їпі сһағѕтодаа) 


спаг5. += сһағгѕТодаа; 
... классы Аадмогаѕ, АЧЧТтадез$ и др. определяются так же ... 
// статистика отображается в диалоговом окне 


моїд 015р1ау(); 
Б 
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Используя классический объектно-ориентированный подход к сбору статистики, 
можно определить в классе босЕ1етепт соответствующую виртуальную функцию. 
с1аѕ5 росЕТетепт 


{ 


// Эта функция-член предназначена для сбора статистики 
уігїіиа1 уоіа ораатеѕтатѕ Сросѕтатѕ& ѕїтатіѕтісѕ) = 0; 


ЕД 
В этом случае каждый конкретный элемент документа может определять эту 
функцию по-своему. Например, классы РагадгарН и Казтегв1ттар, производные от 
класса ОосЕТетепт, могут реализовывать функцию урдате$тат$ следующим образом. 


уоїд Рагадгарн: :ораатеѕтатѕ (оосѕтаёѕ5& ѕ№аїіѕїісѕ) 


ѕтатіѕіісѕ.Ааасһагѕ (количество символов в абзаце); 


ѕтатіѕтісѕ. Аадмогаѕ (количество слов в абзаце) ; 
} 


уоїй Казтегв1ттар: :ораатеѕтатїѕ (росѕтаїѕ& ѕтаїіѕіісѕ) 
{ 


// Этот класс учитывает только рисунки и больше ничего 
// Ссимволь и другие элементы игнорируются) 
ѕ5таїі511сѕ.АЯаІтадеѕ (1); 


В итоге функция, управляющая сбором статистических данных, может выглядеть так. 
\014 боситепт: :91$р1ау$Тат1$11с$() 


росѕќатѕ ѕгатіѕтісѕ; 

Ғог (каждый элемент документа) 

{ 

элемент->урдатезтат$ (ѕ5їаїіѕтісѕ); 
р. Я 
ѕтатіѕтісѕ.ріѕр1ау() ; 


Это очень хорошая реализация возможностей по сбору статистики, однако у нее 
есть ряд недостатков. 


« Она требует, чтобы класс росЕ1етепї и производные от него классы имели 
доступ к определению функции ОосѕЅїаї5. Следовательно, при каждой моди- 
фикации класса рос5татз придется компилировать заново всю иерархию класса 
росЕТетепт. 


» Фактические операции по сбору статистики рассеяны по разным реализациям 
функции ирдатезтат$. При отладке или расширении возможностей, связанных 
со сбором статистики, придется искать и редактировать несколько файлов. 


• Реализация не масштабируется по мере добавления новых операций, аналогич- 
ных сбору статистики. Для того чтобы добавить операцию “увеличить размер 
шрифта на один пункт”, понадобится добавить в класс росЕТетепі новую вир- 
туальную функцию, преодолевая все связанные с этим трудности. 


Однако связь, существующую между классами росЕЛетепї и Оосѕќаїѕ, можно разо- 
рвать, если переместить все операции внутрь класса росѕтатїѕ и позволить ему самому оп- 
ределять, какую операцию выполнять для того или иного типа. Для этого нужно, чтобы в 
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классе росѕтатѕ существовала функция-член уоіа Ирдатезтат$ (росЕТетептё&). Тогда до- 
кумент просто просматривал бы свой элементы и вызывал для каждого из них функцию 
Урдатезтат. | 

Это решение сразу скрывает класс росѕтатїѕ от класса босЕ1етеп*. Однако теперь 
класс рос5тас5 зависит от каждого конкретного объекта класса ОосЕТетепі, который 
необходимо обработать. Если иерархия объектов более постоянна, чем множество 
операций, эта зависимость никому не мешает. Теперь проблема заключается в том, 
что реализация класса џрдӢатеѕтаї5 должна использовать так называемое переключение 
типов (уре змисН). Это переключение возникает при обращении к полиморфному 
объекту по его конкретному типу и выполнении разных операций в зависимости от 
этого типа. Функция рос$тат : : ирдатезтат$ связана с этим переключением типов. 


моїа ОосЅтаїѕ : :урдатеѕтаїѕ (росЕЛетепт& еЛет) 
1Ғ СРагадгарһ* р = дупатіс__саѕт<Рагадгарһћ*> (бе1ет)) 


спаг5- += р->МитСһагѕ О); 
мог4$_ += р->Митмогаѕ () ; 


е1ѕе її (4упам1с_сазт<Казтегв1ттар*> (&е1ет)) 


{ 


++1таде$_; 


е15е 


добавляем по одному оператору і для каждого типа инспектируемого объекта 
} 


(Определение указателя р внутри оператора 1Р вполне законно, поскольку это мало 
известное свойство языка С++. Переменную можно определять и проверять непо- 
средственно внутри оператора 1+. Область видимости этой переменной ограничена 
оператором 1+ и его частью е]зе. Несмотря на то что эта возможность не представля- 
ется нам существенной, и создавать остроумные коды в качестве самоцели не реко- 
мендуется, отметим, что она предназначена именно для переключения типов, так по- 
чему бы не воспользоваться этим?) 

Когда программист видит что-то подобное, у него в голове должен сразу же срабо- 
тать предохранитель. Переключение типов не всегда желательно. (В главе 8 приводит- 
ся детальная аргументация этого утверждения.) Код, основанный на переключении 
типов, трудно понимать, расширять и сопровождать. Он не защищен от случайных 
ошибок. Например, что произойдет, если поставить вызов оператора дупатіс_саѕт 
для базового класса перед вызовом оператора аупам1 с_саз* для производного класса? 
Во время первой проверки будут сопоставляться производные классы, поэтому вторая 
проверка никогда не будет выполнена. Одна из целей полиморфизма — избежать пе- 
реключения типов и связанных с ним проблем. 

Посмотрим, в каких ситуациях может оказаться полезным шаблон \1$1тог. До- 
пустим, нам нужно, чтобы новые функции работали виртуально, но мы не хотим вво- 
дить новые виртуальные функции для каждой операции. Для этого нужно реализовать 
переключающую виртуальную функцию (бомисіпе, міпиа! РласНоп), единственную во всей 
иерархии класса росЕТетепі. Эта функция будет “пересылать” задание в другую ие- 
рархию. Иерархия росЕТетепі называется инспектируемой (хіѕіќей), а операции при- 
надлежат новой иерархии инспектора (уіѕісог). 

Каждая реализация переключающей виртуальной функции вызывает другую функ- 
цию в иерархии инспектора. Так выбираются инспектируемые типы. Функции в ие- 
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рархии инспектора, вызываемые переключаюцісй функцией, являются виртуальными. 
Так выбираются операции. 

Эту идею иллюстрирует приведенный ниже фрагмент кода. Во-первых, мы опреде- 
ляем абстрактный класс росЕЛетепїуіѕітог, в котором определяется операция для 
каждого типа объектов в иерархии класса БосЕ1етепе. 


с1аѕѕ ОосЕТетепсмі5іСсог 


риб'їс: 

уігтиа1 уоїа У15іСРагадгарп(Рагадгаріб) = 0; 

мігсиаї уо14 мі5ісва5сегВістар(ка5СсегВігтаюрі) = 0; 
другие подобные функции 


Затем в иерархию класса БосЕ1етепт добавляется переключающая виртуальная функ- 
ция под названием Ассерс, получаюшая параметр росЕЛетепїуіѕісог& и вызываю- 
щая соответствующую функцию Уї151 ххх. 

с1аѕѕ росЕТетепі 


риБ11с: К 
уігтиа1 уо14 Ассерт (росЕТетепуіѕітогё) = 0; 


}; 
уоіа Рагадгарћ: : Ассер* (росЕТетеп?уіѕісог& у) 


м.М15 і гРагадгари С"СНі5); 


уоіа Ааѕтегвіттар : : Ассерт (БосЕ] етепсмі5ісоге у) 


у.міѕіТАаѕсегВіттар (*һїѕ); 


А вот и функция росЅтаїѕ во всей своей красе. 
с1аѕѕ рос5сас5 : рибТіс росЕ1етептміѕітог 


риБ1їіс: 
мігтиаї уоїй УїѕітрагадгарћСРагадгарћ& раг) 


сһагѕ__ += раг.митсһагѕ О; 
могаѕ_ += раг.митмогаѕ (2; 


уігтиа1 моїй Ууіѕітсваѕтегвігтар (Ваз сегвігтарё&) 


++1таде$_; 


р. 


(Разумеется, реальную реализацию этой функции следует поместить в самостоятель- 
ный файл, отделив ее от определения класса.) 

Этот небольшой пример иллюстрирует недостаток шаблона У1$1тог: виртуальная 
функция-член на самом деле не добавляется. Настоящие виртуальные функции имеют 
полный доступ к каждому объекту, для которого они определены, в то время как из функ- 
ции Уіѕітограгадгарћ можно получить доступ лишь к открытой части класса Рагадгарн. 
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Управляющая функция боситепт : :015р1аузтат1 $11с$ создает объект класса рос- 
5хаї5 и вызывает функцию Ассерї для каждого объекта класса босЕТетепі, переда- 
вая его качестве параметра. Поскольку объект класса росѕїтаїѕ инспектирует разные 
конкретные объекты класса оосЕ1етепт, он отлично собирает все данные, и переклю- 
чение типов совсем не нужно. 


\014 Босиптепт: :015р1ау5та11$11с$ О 


{ 
росѕїаїѕ з5касі5 сіс5; 
Ғог (каждый элемент документа) 
1 
элемент->Ассерт (ѕтатіѕтісѕ); 
1 
ѕіасіѕ1їсѕ.ріѕр1ау(); 
} 


Проанализируем возникающий контекст. Мы создали новую иерархию, корнем 
которой является класс росЕТетеп?уїіѕітог. Это иерархия операций (Пієгагсбу ої 
орегаїііопѕ). Каждый класс, входящий в нее, на самом деле представляет собой 
операцию, например росѕїаїѕ. Теперь добавлять новые операции совсем не- 
сложно. Для этого нужно лишь создать новый класс, производный от класса ро- 
сеЕТетепсуУі5ісог. Ни один элемент иерархии класса росЕТетепі для этого ме- 
нять не требуется. 

Например, добавим одну операцию, скажем, ІпсгетепїЕопї512е, связанную с го- 
рячей клавишей, предназначенной для увеличения размера шрифта на один пункт, 
или соответствующей кнопкой. 


сТа55 ІпсгетепіРопі5іге : рибТіс БосЕТетепісуї5 і ог 


риБ11с: 
мігтиа! моїй \1$1тРагадгари (РагадгарН& раг) 


{ 
раг. ѕетеопїтѕ51ғе(раг.СетЕопїт512е() + 1); 


уігёџа1 моїй у1іѕіїАаѕтегвіїётар(ваѕтегвіїётарё&) 


// ничего не делаем 


}; 

Вот в все. Не нужно вносить никаких изменений ни в иерархию класса 
ОосЕЛетепт, ни в другие операции. Вы просто добавляете новый класс. Функция 
росЕТетеп : :Ассерї перебирает все объекты класса тпсгетепЕРопт51хе совершен- 
но так же, как объекты класса росѕїтаїѕ. Полученная в результате структура классов 
представлена на рис. 10.1. 

Напомним, что по умолчанию новый класс легко добавить, а виртуальную функ- 
цию-член — нет. Мы преобразовали классы в функции с помощью перехода от ие- 
рархии класса босЕТетепі к иерархии класса росЕТетепімі5ісог. Таким образом, 
классы, производные от класса БосЕ1етеп®\/1$1%ог, представляют собой воплощенные 
функции (објесіібеа Гипстіоп5). Так работает шаблон проектирования У15Ног. 
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ОосЕїетепі 


+Ассерцміѕќог : ОосЕетепііѕїог&) 
Д 


Рагадгарһ 


Ассер{{мѕ : ОосЕіетепћіѕКог&) 


Ассері(мівійог : ОосЕіетепіМієйого) 


=2-----4 


СосЕіетепіМѕіїог 


\ѕйРагадгарћраг : Рагадгарһ) 
\ИзИАамегВитар(Ьтр : АазїегВіїтарё) 


Оосбіаїв ІпсгетепіРопібіге 


Рис. 10.1. Иерархия классов для игры с двумя уровнями сложности 


10.2. Перегрузка и функция-ловушка 


Управление перегрузкой функций в языке С++ оказывает очень большое влияние 
на реализацию проектов на основе шаблона уіѕ1ітог, хотя для самого шаблона пере- 
грузка функций значения не имеет. 

В классе росе1етепїуі ѕ1ісог каждому инспектируемому типу соответствует отдельная 
функция-член: у151їрагадгарћСРагадгарћ&), У151твазтегв1 стар(Каз сегві старі) и т.д. 
Эти функции явно избыточны. Кроме того, имя инспектируемого типа является частью 
самой функции. 

Как правило, избыточности лучше избегать. Для этого следует применять пере- 
грузку функций. Мы просто назовем все функции одним именем \У1$1* и предоста- 
вим компилятору решать, какую перегруженную функцию \1$11 вызывать для пере- 
даваємого параметра заданного типа. Альтернативое определение класса БосЕ]е- 
тепсмі $1тог выглядит следующим образом. 


с1а$$ БосЕТетепсУї51сог 


{ 

риБ1їіс: . 
мігсиа? моїд Уі5іс(Рагадгарнбд) = 0; 
мігсиа! моїд У1511САаѕтегвіттар&) = 0 
... другие подобные функции... 


}; 
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Теперь можно проще определить функции-члены Ассерт, поскольку их поведение 
становится единообразным. | 


уоіа Рагадгарі: : Ассер® (БосЕТетепт\1 51тог& м) 


м.Мі51С("1515); 


моїй Ваз5сегВіхтар: : Ассерї (росЕЛетепїмї 51 тог& м) 


м.міѕіЕС%Ећ15); 


Они выглядят настолько одинаковыми, что может возникнуть соблазн перенести их в 
базовый класс росЕ1етепт. Это было бы ошибкой. На самом деле это совершенно 
разные функции. Параметр *1һ15 в функции Рагадгарй: :Ассерф имеет статический 
тип РагадгарН&, а в функции Ћаѕ®егВвіїтар::Ассерт — тип Ћаѕ№егВіттар&. Именно 
эти статические типы помогают компилятору правильно определять, какую из пере- 
груженных функций босЕТетеп М1 $1тог: :У1 $11 следует вызывать. Если бы функция 
Ассерт была реализована в классе босЕТетепі, параметр *1ћі5ѕ имел бы статический 
тип БосЕЇетепіб, который не может предоставить компилятору всю необходимую 
информацию. Таким образом, факторизация классов не должна быть произвольной. 
Неправильная факторизация может привести программу в негодность. 

Перегрузка функций порождает интересную идею. Допустим, что все классы, про- 
изводные от класса росЕТетепї, реализуют функцию Ассерт, просто переадресовывая 
вызов функции росЕЛТетепї\№і51їіог::У1511. Тогда в классе росеЛетепї можно опре- 
делить следующую перегруженную функцию-ловушку (сафсН-аЙ оуепоаа). 

сТа55 росЕТетептміѕ1ітог 


риббіс: 
как и прежде ... 
уігтиа?! моїа “151тСросЕТетепе&) = 0; 


Ы 

Когда будет вызываться эта перегруженная функция? Если новый класс является 
непосредственным наследником класса росЕЛ1етепї и в классе росЕЛТетепіуіѕітог 
для него нет подходящей перегруженной функции \15$1т, то вступают в силу правила 
перегрузки и автоматического преобразования производных типов в базовые. Ссылка 
на объект неизвестного класса автоматически конвертируется в ссылку на объект ба- 
зового класса ОосЕТетепт, и вызывается функция-ловушка. Если такой функции нет, 
возникает ошибка компиляции. Предусматривать функцию-ловушку или нет, зависит 
от конкретной ситуации. 

В перегруженной функции-ловушке можно выполнить много полезной работы. 
Примеры представлены в работах Влиссидеса (№]іѕѕійеѕ, 1998, 1999). В такой функции 
можно выполнять произвольные действия весьма обобщенного характера или прибег- 
нуть в переключению типов (используя оператор 4упат1 с_сазт), чтобы распознать 
фактический тип параметра БосЕ1етепт. 


10.3. Уточнение реализации: шаблон Асусйс Мі5іїог 


Итак, вы решили применить шаблон міѕітог. Вас интересует, как это сделать в 
реальном проекте? 
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Анализ зависимостей между классами в предыдущем примере приводит нас к сле- 

дующим выводам. 

» Для того чтобы скомпилировать определение класса ОосЕТетепі, необходимо 
знать о существовании класса росЕ1етептуїѕ1тог, поскольку он упоминается в 
сигнатуре функции-члена росЕЛетепт: :Ассерт. Для этого достаточно сделать 
неполное объявление класса (огмагА дес1агаНоп). 


е Для того чтобы скомпилировать определение класса босЕТетепе\1 51 сог, необ- 
ходимо знать о существовании всех конкретных классов, входящих в иерархию 
класса босЕТетепі, поскольку имена этих классов встречаются в функциях- 
членах м15іїХхх класса ООСЕТетепту15 і ог. 


Такой тип зависимости называется циклическим (сусіїс Ферепаепсу). Циклические 
зависимости создают хорошо известные трудности. Для класса росЕТетепі необходим 
класс росЕТетепїуіѕітог, а классу росЕТетепїуіѕітог нужны все классы из иерар- 
хии класса босЕ1етепт. Следовательно, класс росЕЛемепї зависит от всех своих под- 
классов. Фактически здесь проявляется циклическая зависимость по имени (сусіїс пате 
ерепаепсу), т.е. для компиляции определений классов нужны лишь их имена. Таким 
образом, классы следует разделить по файлам. 

// Файл ОосЕТетепїміѕітог.һћ 

сТа55 босЕ1етеп*; 

сТа55 Рагадгарһ; 


с1аѕѕ Казтегв1ттар; 
неполные объявления всех подклассов класса росЕЛетепї 


с1аѕ5 ОросЕТемепїуіѕітог 


мігєцаї у014 Ууіѕ1іТРагадгарћ (Рагадгарћё&) = 0; 
мігхцаї уоїд уіѕіткаѕтегвіттар(каѕтегвіїтар&) = 0; 
другие подобные функции 


Н 
// Файл ОосЕТемепт. һћ 
с1аѕ5 ОросЕТетептуіѕітог; 


сТа55 ОосЕЛемепт 


риБ1іс: 
уігтџа1 моїд Ассерї (оосЕТетептуіѕітогё) = 0; 


}; 

Более того, для каждой однострочной реализации функции Ассере необходимо знать 
определение класса росЕЛетепїуіѕіїог, а каждый конкретный инспектор должен 
быть внедрен в класс, который он должен инспектировать. Все это порождает весьма 
запутанную схему взаимозависимостей. 

Добавлениє новых подклассов класса росє?етепс становится крайне сложным. Но ведь 
мы и не собирались добавлять в иерархию класса росЕЛемепї никаких новых элементов! 
Шаблон Уіѕітог предназначен прежде всего для устойчивых иерархий, в которые добав- 
ляются лишь операции, а не новые классы. Стоит напомнить, что шаблон уіѕі?ог позво- 
ляет это сделать за счет усложнения процедуры добавления новых производных классов в 
инспектируемую иерархию (в нашем примере — в иерархию класса росЕЛемеп?). 

Однако жизнь — сложная штука. В реальном мире устойчивых иерархий вообще 
не бывает. Когда-нибудь вам понадобится добавить новый класс в иерархию класса 
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росЕТетепі. В предыдущем примере для этого придется добавить новый класс мес- 
ТогбсгарН1с, производный от класса росЕ1етепї. Следуйте нашим указаниям. 


• Откройте файл БосЕТетептМіз5ісог.П и добавьте новое неполное объявление 
класса Местогсгарһћіс. 


• Включите в класс босЕ1етепт новую чисто виртуальную перегруженную функцию. 
с1аѕѕ росЕТетептуіѕітог 


з как и прежде ... 
мігіца1 моїй Уі5і гУестогсгарніс(местогсгарніса) = 0; 


; 

• Реализуйте в каждом конкретном инспекторе функцию уїіз і тУестогбгарііс. 
Эта функция может быть пустой. В качестве альтернативы можно определить 
пустую функцию ФРосЕТетептмі5ігог::Мі5іУестогсгарініс, однако в этом 
случае компилятор не сообщит ничего, если вы забудете реализовать ее в кон- 
кретных инспекторах. 


е Реализуйте функцию дссерт в классе УестогбгарИ1с. Сделайте это обязательно. 
Если, применяя прямое наследование от класса БосЕ1етепт, вы забудете реализо- 
вать функцию Ассерх, ничего страшного не произойдет — вы получите сообщение 
об ошибке компиляции. Однако, если вы выполните наследование от другого клас- 
са, например, класса бгарпіс, в котором определена функция дссерт, компилятор 
не проронит ни слова о том, что вы забыли сделать класс Уесїогсгарћіс инспекти- 
руемым. Эта ошибка проявится лишь во время выполнения программы, когда вы с 
удивлением обнаружите, что ни одна реализация функции У151Мессогбгар 1с не 
вызывается. Найти такую ошибку достаточно сложно. 


Следствие: все иерархии классов босЕТетепс и росЕТетептуіѕітог будут скомпили- 
рованы повторно, и вам придется добавлять довольно большое количество механиче- 
ского кода лишь для того, чтобы. сохранить работоспособность программы. В некото- 
рых случаях такое решение может оказаться совершенно неприемлемым. 

Роберт Мартин (Вобеп Мапіп, 1996) изобрел интересную разновидность шаблона 
\151тог, в котором цикличность ликвидируется с помощью оператора йупатіс_саѕї. В 
рамках этого подхода для иерархии инспектора создается фиктивный базовый класс 
Ваѕеуіѕ1ітог, выступающий в роли носителя информации. Он не имеет никакого содер- 
жания, а следовательно, совершенно независим. Функция-член Ассері из инспектируемой 
иерархии получает ссылку на объект класса ваѕеміѕітог и применяет к нему оператор ду- 
пат1с_са$%, чтобы обнаружить соответствующий инспектор. Если соответствие достигну- 
то, функция Ассерт переходит от инспектирусмой иерархии к иерархии инспектора. 

Это звучит довольно загадочно, но на самом деле все очень просто. Посмотрим, 
как можно реализовать шаблон Асусіїс  Мі5ісог в проекте росЕТетепт/ 
росЕТетепїуіѕітог. Во-первых, определим базовый класс инспектора. 

сТа55 БбосЕТетептУЇї5ітог 

{ 

риБ11с: 

УТгтиа] уо14 -ОосЕТетептуУї5ісогО {} 

}; 

Пустой виртуальный деструктор выполняет две важные вещи. Во-первых, он пре- 
доставляет в распоряжение класса росЕТетепїуіѕітог функциональные возможности 
механизма ЕТТІ (гипііте їуре іпѓогтайоп). (Оператор дупатіс_саѕї можно применять 
лишь к тем типам, которые содержат хотя бы одну виртуальную функцию.) Во- 
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вторых, виртуальный деструктор гарантирует корректное полиморфное уничтожение 
объектов класса росЕ1етепїуіѕітог. Полиморфная иерархия без виртуальных дест- 
рукторов вызывает непредвиденные последствия, если объект производного класса 
разрушается через указатель на объект базового класса. Таким образом, обе опасности 
устраняются всего одной строчкой кода. 

Определение класса БосЕ1Летепх остается прежним. Для нас представляет интерес 
определение чисто виртуальной функции Ассерт (росЕ1етепсмі5 1 согб). 

Затем для каждого производного класса в инспектируемой иерархии (корнем кото- 
рой является класс РосЕТетепт) определим небольшой инспектирующий класс, 
имеющий только одну функцию Ууіѕіїххх. Например, для класса Рагадгарн нужно 
определить следующий класс. 


с1аѕѕ Рагадгаріміз5ісог 


рыб] 1с: 
уігсиа1 моїй уіѕітрагадгарћ(рагадгарћ&) = 0; 


з 
Реализация функции Рагадгарн: :Ассерт выглядит так. 
уоіа Рагадгарй: : Ассер* (М1 $1тог& у) 


1+ СРағадгарһћуіѕітог* р = 
дупатіс са5 «РагадгарНйуї15 і $ог*> (&м)) 


р->УїѕіТРагадгарћ(*1ћіѕ) ; 
еї5е 


здесь можно вьізвать функцию-ловушку 
} 
} 
Ведущую роль в этой функции играет оператор дупатіс_саѕс, позволяющий системе 
поддержки выполнения программ распознать, является ли объект у подобъектом 
класса РагадгарНну151 бог, и, если да, получить указатель на этот подобъект. 
Аналогичные реализации функции Ассерт определяются во всех классах, производных 
от класса осЕ1етепх. В заключение конкретный инспектор выводится из класса босЕ1е- 
мепЕ\1$1тог и базовых инспекторов для всех классов, представляюших интерес. 
с1а$$ росѕтаїѕ : 
руб]11с босЕТетепсмізітог, // необходим 
рчЬ1іс Рагадгарћуіѕітог, // Нужен для инспектирования 
// объектов класса Рагадгарн 


рчЬ1іс ка5сегвістарміз5ісог, // нужен для инспектирования 
// объектов класса ВаѕтегВіїтар 


{ 
риБ11іс: , 
\014 Уї517Рагадгарһ(Рагадгарћ& раг) 


сһагѕ_ += раг.митсһагѕ() ; 
мог4$_ += раг. митмогаѕ () ; 


уоїд У1511Ааѕтегвістар(ваѕтегвіттарё) 
{ 


++1таде$_; 
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Структура классов, полученная в результате, показана на рис. 10.2. Горизонтальные пунк- 
тирные линии изображают зависимости, существующие в иерархии, а вертикальная — 
границу между иерархиями. Обратите внимание на то, как оператор Чупам1 с_сазт позво- 
ляет волшебным образом перескакивать с одного иерархического дерева на другое, исполь- 
зуя в качестве пружины фиктивный класс босЕ]етеп\У1 $1 ок. 


зАссері(мізйог: СосЕіетепіУіѕіїог&) 
Д 


Рагадгарћ 


Ассері{мѕ : ВосЕіетепМіѕйїогё) 


ВацегВ тар 


Ассер{{міѕќог : росЕіетепМіѕїог&) 


Оосбіаїв 


РагадгарћМіѕйог ВаегВИтар\М Ног 


БосНетеп Ног 


Рис. 10.2. Структура классов для ациклического инспектора 


Хотя описанная структура содержит в себе большое количество деталей и взаимо- 
действий, базовая структура довольно проста. Убедимся в этом, проанализировав по- 
ток событий. Допустим, что у нас есть указатель рроосЕТет на объект класса росЕЛе- 
тепе, имеющего динамический (“реальный”) тип Рагадгарй. Тогда поступим сле- 
дующим образом. 

рос5сас5 ѕ№аїѕ; 

роосеТеп-»Ассерс(5 саєс5); 


Это повлечет за собой такие события. 


1. Объект 5сас5 автоматически преобразовывается в ссылку на объект класса рос- 
ЕТепепімїі 5 і сог, поскольку он является открытым наследником этого класса. 


2: Вызывается виртуальная функция Рагадгарй : : Ассерї. 
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3. Функция РагадгарН::Ассерт пытается применить оператор Яу- 
паті с._саѕї<Рагадгарћуїѕітог*> к адресу объекта росЕ1етептуїѕітог, по- 
лученного ею в качестве параметра. Поскольку этот объект имеет динамиче- 
ский тип росЅїаїѕ, который является открытым наследником классов ро- 
СЕТетептуіѕітог и рагадгарһуіѕітог, выполняется приведение типов. 
(Вот где происходит телепортация!) 


4. Теперь функция РагадгарН: : Ассерт должна получить указатель на часть класса 
РагадгарН\1 1тог, которую унаследовал объект росѕЅїаїѕ. Функция Рага- 
дгарһ::Ассерт применяет к этому указателю виртуальную функцию \1$11- 
Рагадгарн. 


5. Виртуальный вызов достигает функции оос5тат$ : :У1$1тРагадгарН. Кроме то- 
го, она получает в качестве параметра ссылку на инспектируемый абзац. Ин- 
спектирование закончено. 


Проверим новую диаграмму зависимостей. 


® Определение класса ОосЕТетепі зависит от класса росЕ1етепїміѕітог по име- 
ни. Зависимость по имени означает, что неполного объявления класса росЕ1е- 
мепїуіѕітог вполне достаточно. 


® Класс Рагадгарһуіѕітог — и вообще все базовые классы хххүіѕіїог -- зави- 
сят по имени от классов, которые они инспектируют. 


« Реализация функции РагадгарН: :Ассерф полностью зависит от класса Рага- 
дгарнмі $1тог. Полная зависимость означает, что для компиляции кода необхо- 
димо полное определение класса. 


• Все конкретные определения классов инспекторов полностью зависят от класса 
росЕТетептуі 51 ог и всех базовых инспекторов Ххх/1$1тог. 


Шаблон Асус11с \У1$1тог ликвидирует циклические зависимости, но взамен ос- 
тавляет программисту еще больше работы. Теперь мы должны поддерживать два па- 
раллельных множества классов: инспектируемую иерархию, корнем которой является 
класс росЕТетепт, и множество инспектирующих классов Хххміз5іїог, по одному на 
каждый инспектируемый класс. Работать с двумя параллельными иерархиями классов 
нежелательно, поскольку для этого требуется строгая дисциплина и внимание. 

Сравнивая эффективность “простого” шаблона М1 $1тог и шаблона Асус1іс У151- 
ток, следует заметить, что во втором случае при каждом проходе иерархии возникает 
одно дополнительное динамическое приведение типов. Время, затрачиваемое на это 
приведение, может быть постоянным, а может зависеть от количества полиморфных 
классов, возрастая по логарифмическому или линейному закону. Вид этой зависимо- 
сти зависит от конкретного компилятора. Если эффективность является важным кри- 
терием качества программы, то эти затраты времени могут стать существенными. Та- 
ким образом, иногда следует использовать “простой” шаблон М151тог и поддерживать 
циклические связи. 

Глядя на эту мрачную картину, следует признать, что шаблон Мі5іїог представля- 
ет собой противоречивую конструкцию. Это не удивительно, поскольку даже Ральф 
Гамма (Ка! Сатта) из группы СоЕ заявлял, что шаблон У151тог замыкает десятку 
самых непопулярных шаблонов (“1іѕѕійеѕ, 1999). 

Шаблон Уіѕітог грубый, негибкий, его трудно расширять и поддерживать. Одна- 
ко, будучи настойчивыми и прилежными, мы можем создать библиотечную реализа- 
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цию шаблона Мізітог, представляюшую собой полную противоположность сказан- 
ному выше: ее легко использовать, расширять и поддерживать. Как это сделать, мы 
покажем в следующем разделе. 


10.4. Обобщенная реализация шаблона Мі5іїог 
Разделим реализацию на две основные части. 


» Инспектируемые классы. Это классы, входящие в иерархию, которую мы соби- 
раемся инспектировать (добавляя в нее операции). 


е Инспектирующие классы. Эти классы определяют и реализуют фактические 
операции. 


Наш метод прост: мы стремимся вынести в библиотеку максимальную часть кода. 
Если нам это удастся, взаимозависимости между классами значительно упростятся. 
Таким образом, инспектор и инспектируемый будут зависеть не друг от друга, а от 
библиотеки. Это очень хорошо, поскольку библиотека считается намного более по- 
стоянной, чем приложение. 

Сначала мы попробуем реализовать обобщенный шаблон Асус1іс Уіѕ1їог, по- 
скольку он обладает лучшими качествами с точки зрения зависимостей между его час- 
тями. Позднее мы его усовершенствуем, повысив эффективность. В заключение вер- 
немся к реализации классического шаблона уіѕітог, предложенного группой СоЕ, 
обладающего более высоким быстродействием за счет потери гибкости. 

При обсуждении вопросов реализации мы будем пользоваться именами, перечис- 
ленными и определенными в табл. 10.1. Некоторые из этих имен на самом деле опи- 
сывают шаблонные классы, точнее говоря, становятся шаблонными классами по мере 
повышения степени обобщенности нашей программы. Пока нас будут интересовать 
лишь определения сущностей, к которым относятся эти имена. 


Таблица 10.1. Имена компонентов 


Имя Принадлежность Описание 
ВаземізісабТ'е Библиотека Основа всех инспектируемых иерархий 
мізітабЛе Библиотека Смешанный класс, благодаря которому класс в 
инспектируемой иерархии становится 
инспектируемым 
росЕЛетепт Приложение Основа иерархии, которую мы хотим сделать 
инспектируемой 
Рагад гарһ, Приложение Два конкретных инспектируемых класса, 
КаѕтегВїїтар производных от класса ООСЕТетепі 
Ассерї Библиотека и Функция-член, которая вызывается для 
приложение инспектирования иерархии 
ваѕеуіѕіїог Библиотека Основа инспектирующей иерархии 
мі51ітог Библиотека Смешанный класс, благодаря которому класс в 
инспектирующей иерархии становится 
инспектирующим 
Ѕтатіѕтісѕ Приложение Конкретный инспектирующий класс 
Уі5їТ Библиотека и Функция-член, которая вызывается 
приложение инспектируемыми элементами и применяется к 
инспекторам 
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Сначала обратим внимание на инспектирующую иерархию. Здесь все довольно 
просто — мы должны предусмотреть некоторые базовые классы для пользователя, т.е. 
классы, определяющие операцию \1$1+ для заданного типа. Кроме того, необходимо 
создать фиктивный класс, используемый оператором динамического приведения ти- 
пов в соответствии с шаблоном Асус1іс “іѕ1ітог. | 


с1аѕѕ Ваѕеуїѕітог 

Са 

риБ11с: 

мігсца! ~Ваѕеміѕісог() {} 
Н 

Кода для повторного применения здесь немного, но иногда приходится создавать и 
такие маленькие классы. 

Теперь напишем простой шаблонный класс У1$1тог. 


тетрТасе «сТа55 Т> 
с1аѕѕ уіѕіїог 


И 
риБ11с: . 
мігсиа1 моїад \1$1%(т&) = 0; 
; 

В общем случае функция Ууіѕіїог<Т>::у151є может возвращать значение, тип ко- 
торого отличается от типа усій. Эта функция может передавать полезный результат 
через функцию Уі5ісарТе: :Ассері. Следовательно, в класс У1$1тог нужно добавить 
второй шаблонный параметр. 


тетр1ате <с1аѕ5 Т, турепате в = моїа» 
сТа55 Мізісог 


Саат 
рибТіс: 
хуредеї т ветигптуре; 
уігсиа1 Весигптуре міз5іс(тв) = 0; 
; 
Для того чтобы проинспектировать иерархию, мы должны создать класс Сопсгете- 
\1$1тог, производный от класса Вазе\1$1хог, а количество реализаций класса У1$1- 
тог должно совпадать с количеством инспектируемых классов. 


сТа55 Ѕотеуіѕітог : 
рибТіс вазеу1$1тог // необходим 
риБ1їс мі5ітзог«Ва5сегвВістар», 
рибТіс Ммі5і сог«Рагадгаріп» 


{ 

рибЛ1с: 
моїд уУї5іс(Ва5сегВістара) // Инспектирует класс ВЋаѕтегВіїтар 
моїй У151єС(Рагадгарібд // инспектирует класс Рагадгарн 


; 

Этот код выглядит простым, ясным и легким в использовании. Его структура четко 
указывает, какие классы подлежат испектированию. И, что еще лучше, компилятор не 
позволяет конкретизировать класс 5отемі 5 і сог, если мы не определили все функции 
у1і51т. В этом проявляется связь между определением класса 5отемі51і ог и именами 
инспектируемых им классов (ВаѕїтегВіїтар и РагадгарН). Эта зависимость вполне 
понятна, поскольку класс 5отем'і 51 сог знает об этих типах и нуждается в специаль- 
ных операциях для работы с ними. 

На этом мы завершим обсуждение части реализации, касающейся инспектирую- 
щих классов. Мы определили простой базовый класс Ваѕеуіѕітог, действующий как 
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оболочка оператора 4упат1с_са$*, и шаблонный класс уіѕітог, генерирующий чисто 
виртуальную функцию \15$1т. 

Несмотря на то что код, написанный нами для этого, весьма мал, его потенциал 
повторного использования огромен. Шаблонный класс уіѕітог генерирует отдельный 
тип для каждого инспектируемого класса. Пользователь библиотеки теперь может не 
разбивать реализацию на такие маленькие классы, как Рагадгарһуіѕітог и Ваѕтег- 
міз5ітог. Типы, генерируемые шаблонным классом Міз5ітог, сами обеспечат связь 
между всеми инспектируемыми классами. | 

Перейдем к инспектируемой иерархии. Как указывалось в предыдущем разделе, 
инспектируемая иерархия в реализации шаблона Асус11с уіѕітог предназначена для 
решения следующих задач. 


» Обьявлять чисто виртуальную функцию Ассерт, получающую ссылку на объект 
класса У1$1тог в базовом классе. 


е Замещать и создавать реализацию функции Ассерт в каждом производном 
классе. 


Для того чтобы выполнить первую задачу, мы добавим в класс Ва5емі5ітабТе чис- 
то виртуальную функцию и потребуем, чтобы класс росЕ1етепт наследовал ее. Это 
относится и ко всем корням инспектируемых иерархий, существующих в приложе- 
нии. Класс ВаѕеуіѕітаБ1е выглядит следующим образом. 


тетр1ате <+урепате В = мої» 
с1а$$ ВаѕеуіѕіїаБ1е 


рыубБ11с: 
суредеї в Аеїигптуре; 
мігсца?! ~ВаѕеуіѕітаБ1е() {} 
уігсиа1 ВетигпТуре Ассерт (Ваѕеуіѕітог&) = 0; 

$; 

Все очень просто и скучно. Интересные вещи происходят, лишь когда мы пытаемся 
выполнить вторую задачу, т.е. реализовать функцию Ассерт в библиотеке (а не в клиент- 
ском коде). Реализация функции Ассері невелика, но включать ее в каждый клиентский 
класс — слишком утомительное занятие. Было бы здорово, если бы этот код принадлежал 
библиотеке. Как предписывает шаблон Асус1іс \М1$1тог, если класс Т является инспекти- 
руемым, то реализация Т: :Ассерї применяет оператор аӢупатіс_саѕт<Уіѕітог<Т>*> к ти- 
пу Ва5емі51сог. Если приведение выполнено успешно, функция Т::Ассерї возвращает 
управление функции \1$1тог<Т>: :у1517. Однако, как указывалось в разделе 10.2, простое 
определение функции Ассерх в классе ВаѕеуіѕітаБ1е не работает, поскольку параметр 
*тһіѕ имеет статический тип Ва5емі5ітабТе, который не может предоставить инспекто- 
рам достаточный объем информации о типе. 

Нужно найти способ реализовать функцию Ассерї в библиотеке, а затем вставить ее в 
иерархию класса босЕ1етепт. Увы, в языке С++ такого непосредственного механизма нет. 
Есть средства для работы с виргуальным наследованием, однако они работают не лучшим 
образом. Мы должны прибегнуть к макросу и потребовать, чтобы каждый класс в инспек- 
тируемой иерархии использовал этот макрос в своем определении. 

Принять решение использовать макрос (со всеми вытекающими отсюда последст- 
виями) нелегко, но другого более удобного и эффективного решения не существует. 
Поскольку программисты на языке С++ люди практичные, эффективность является 
достаточной причиной для использования именно макроса, а не другого, эзотериче- 
ского, но неэффективного средства. 
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Основное правило гласит: макрос должен выполнять как можно меньше работы и 
как можно быстрее пересылать данные “реальным” сущностям (функции или классу). 
Макрос для инспектируемых классов определяется следующим образом. 

#ЧеЁ1пе ОЕРІМЕ МІ5ІТАВЦЕО \ 


мігсиаї вдефигптуре Ассерї (Ваѕеуіѕіїог& диеѕї) \ 
{ гекигп АссертїІтр1 С*1һ15, диеѕї); } 


Пользователь должен вставить макрос РЕЕІТМЕ МІЗ5ІТАВЦЕ (0) в каждый класс ин- 
спектируемой иерархии. Этот макрос переопределяет функцию-член Ассер* как шаб- 
лонную функцию Ассеріітрі, параметризованную типом параметра *їһіѕ. Таким 
образом, функция Ассереттр1 получает доступ к необходимому статическому типу. 
Функция Ассеріїтрі определена в самом низу иерархии, в классе Ва5емі5іїог. Это 
позволяет всем производным классам иметь к ней доступ. Вот как выглядит изменен- 
ный класс Ва5еуї5 1та Те. 


хетрТасе <турепате А = моїа» 
с1аѕ5 Ваземі5ісарбТе 


{ 
рибТтіс: 
Хуредеї в ветигптуре; 
У1Тгтиа] ~ВаѕеуіѕітаЫ1е() {} 
мігіцаї кетигптуре Ассер1(Ваѕеуіѕісог&) = 0; 
ргофестед: // Открывает доступ к иерархии 
тетрТате «сТа55 т> 
ѕїабіс Кекигптуре Ассерхттр1 (тё мі5ісед, Ваѕеуіѕітсогё диеѕтї) 


// применяем шаблон АсусТіс Уіѕіїог | 
ЇР (Мі5ісогхть" р = дупат1с_са$1<\1$1тог<Т>*> (&дие$т)) 


геёигп р->УіѕіїСуїѕітеа) ; 


гетигп кетигптуре(); 
} 

}; 

То, что мы отправили функцию АССерїІтр1 в библиотеку, очень важно. Это сде- 
лано не только для автоматизации работы пользователя. Присутствие функции Ассер- 
тІтр1 в библиотеке дает нам возможность настраивать ее реализацию на конкретные 
условия проекта. 

Реализация проекта У151хог/\1 $1 та Ле скрывает от пользователя большое коли- 
чество деталей, представляя собой волшебный черный ящик. Ниже приведен код реа- 
лизации обобщенного шаблона Асус1іс уіѕ1їог. 


// Инспектирующая часть 
с1а55 Вазе\у1$1тог 


е 
риБ1іс: 
мігтиа! ~Ваѕеуіѕітог() {} 
}; 
хетрТасе <с1а55 Т, турепаще в = \у014> 
сТа55 У151тог 


{ 
риБ1їс: 


туредеїб в ветигптуре; // Доступен для клиентов 
у1гЕиа1 ветигптуре у1511СТт&) = 0; 
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// инспектируемая часть ' 
Тетр1ате «Сурепате в = усій» 
с1аѕ5 Ваземі5ісабТе 


{ 
риБ1їс: 
суреде? к Кетигптуре; 
уігіиа1 ~ВаѕеуіѕітаБ1е() {} 
уігсиа1 ветигптуре Ассерт (Ваѕеуіѕітсогё&) = 0; 
ргосестеа: 
тетр1ате <с1а55 т> | 
5сасіс ВекигпТуре АссертІтр1 (Т& у151%е4, Ваѕеуїѕісог& диеѕї) 


// Применяем шаблон АсусТіс Уіѕітог 
ЇР (у151тог<Тт>* р з дупам1с_са${<\15$1тог<Т>*> (&9иеѕ1)) 


гетиги р-»мі51С(у151сеа); 


гетигп ветигптуре(; 
) 
}; 


#4еР1пе БЕЕІМЕ МІ5ІТАВНЕО \ 
уігіиа1 кетигптуре Ассерт (вазе\1$1тог& диеѕї) М 
{ гресигп Ассертттр1 С®ћі5, дие5 с); 


Готовы к тестовым испытаниям? Начнем! 
сТа55 бросЕЇетепі : рибТіс ВаѕеуіѕітаБ1е<> 


рибііс: 
ОЕҒІМЕ_УІЅІТАВІЕ 0 


с1аѕѕ Рагадгаріп : рибТіс босЕТетепі 


р 
риБ1їс: 
ОЕРІМЕ _УІЅІТАВІЕ () 


сТа55 мусопсгетеуіѕітог : 
рир1іс ваѕеуіѕітог, // необходим 
рчЬ1іс Ммі5ісог«росЕТетепі», // инспектирует объекты 
/ класса босЕТетепт$ 
риБ1їс Мі5ісог«Рагадгарі» // инспектирует объекты 
5 // класса Рагадгарі 


{ 
риБ11с: 
уоіа №М151%(БосЕ]етепт&) 
{ $&4::соч® << "М1 51% (БосЕ1етепе&) \п"; } 
уоїй М151%(РагадгарН&) 
{ $Е4::соче << "№1511 (Рагадгарһ&) \п"; } 


; 
іпс татпОо 


мусопсгетеу1$1тог міѕітог; 

РагадгарН раг; 

босЕТетепіХ а = &раг; // Скрывает статический тип объекта раг 
а->Ассерї (Уіѕітог); 


272 Часть 11. Компоненты 


Эта маленькая программа выводит на экран сообщение, означающее “все в порядке”. 
\1$11 (РагадгарН&) | 


Разумеется, этот искусственный пример не может продемонстрировать всю мощь 
разработанного нами кода. Однако, если вспомнить, с какими трудностями мы столк- 
нулись в предыдущем разделе при реализации инспекторов “с нуля”, становится ясно, 
что теперь в нашем распоряжении есть средство для корректного создания инспекти- 
руемых иерархий и их дальнейщего инспектирования. 

Перечислим действия, которые необходимо выполнить при определении инспек- 
тируемой иерархии. 


• Вывести корень иерархии из класса Ваземі5 і габТехуоигветигптуре». 


- Добавить в каждый класс 5отеСТа55, входящий в инспектируемую иерархию, 
макрос ОЕБІМЕ МІ5ІТАВІЕ (0. (Теперь иерархию можно инспектировать, однако 
никаких зависимостей от класса \1$1тог больше нет!) 


• Вывести каждый конкретный инспектирующий класс из класса Вазе\м1$1тог. 
Кроме того, для каждого класса х, подлежащего инспектированию, нужно вы- 
вести класс ботем1$1тог из класса Мі5ісог«Х, уоигкетигитуре>. Обеспечить 
замещение функции-члена Мі 5 ії в каждом инспектируемом классе. 


Диаграмма зависимостей, возникающая в результате этих действий, очень проста. 
Определение класса $оте\1$1тог зависит по имени от каждого инспектируемого 
класса. Реализации функции-члена Мі5іс полностью зависят от классов, которыми 
они манипулируют. 

Все это прекрасно. По сравнению с реализациями, обсуждавшимися ранее, луч- 
шего и быть не может. Благодаря реализации шаблона Мі5іїог у нас есть упорядо- 
ченный способ создания инспектируемых иерархий, позволяющий сократить клиент- 
ский код и зависимость классов. 

В особых случаях функцию Ассері лучше реализовывать непосредственно, а не с по- 
мощью макроса БЕРТМЕ_МТЗТТАВЕЕ(). Допустим, что мы определяем класс Ѕестіоп, про- 
изводный от класса росЕ1етеп? и содержащий несколько объектов класса Рагадгарћ. Мы 
бы хотели инспектировать все объекты класса Рагадгарй, содержащиеся в объекте класса 
5есіїоп. В этом случае мы могли бы реализовать функцию Ассерт вручную. 

сТаз55 5ессіоп : рибТіс росЕТетепі 


// Функция Ассерт реализуется непосредственно, 
// а не через макрос ОЕЕІМЕ МІЗ5ІТАВІЕ () 


мі гума Ветигптуре Ассерт (ваѕеміѕ1тог& у) 
1 
Ғог (каждый параграф в данном разделе) 
{ 


сиггепт_рагадгарН->Ассерт (У); 


} 

}; 

Очевидно, что с помощью шаблона уіѕіїтог можно делать все, что угодно. Код, 
приведенный выше, освобождает программиста от тяжелой необходимости создавать 
все с НУЛЯ. 

Мы закончили разработку ядра реализации шаблона уіѕітог, содержащего прак- 
тически все, что необходимо для инспектирования, Продолжение следует. 
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10.5. Назад — к “простому” шаблону Міѕіїог 


Реализация обобщенного шаблона АсусТіс міз5ітог, определенная в предыдущем 
разделе, вполне удовлетворительно работает во многих ситуациях. Однако, если нуж- 
но создать быстродействующее приложение, динамическое приведение типов, выпол- 
няемое в функции Ассерт, может повергнуть вас в уныние, а измерения скорости ра- 
боты вашей программы — прямо в состояние депрессии. Почему это происходит? 
Когда вы применяете оператор дупатіс са5ї к некоторому объекту, система под- 
держки выполнения программ должна произвести несколько действий. Код механиз- 
ма КТИ! должен определить, допустимо ли данное преобразование, и в случае поло- 
жительного ответа вычислить указатель на объект результирующего типа. 

Попробуем разобраться, как этого можно достичь при создании компилятора. Мож- 
но присвоить каждому типу, который фигурирует в программе, уникальный целочис- 
ленный идентификатор. Этот идентификатор оказывается полезен и при обработке ис- 
ключительных ситуаций. Тогда в виртуальную таблицу каждого класса компилятор за- 
писывает указатель на таблицу идентификаторов всех его подтипов. Вместе с ними 
компилятор должен хранить смешения подобъектов относительно базового объекта. 
Этой информации достаточно для правильного выполнения динамического приведения 
типов. Когда выполняется оператор дупаті с_са$т<т2*>(р1), а параметр рі представля- 
ет собой “указатель на объект типа Т1”, система поддержки выполнения программ про- 
сматривает таблицу типов в поисках типа, соответствуюшего типу Т2. Если соответствие 
с типом Т2 обнаружено, система поддержки выполнения программ выполнит необходи- 
мые арифметические операции с указателем и вернет результат. В противном случае бу- 
дет возвращен нулевой указатель. Детали, в частности множественное наследование, еше 
больше усложняют и замедляют динамическое приведение типов. 

Сложность описанного выше решения равна О(п), где п — количество базовых классов 
данного класса. Иными словами, время, затрачиваемое на динамическое приведение ти- 
пов, возрастает линейно по мере углубления и расширения иерархий наследования. 

В качестве альтернативы можно использовать таблицы хэширования, позволяюшие 
повысить быстродействие программы за счет болыних затрат памяти. Кроме того, 
можно применить болыную матрицу для всего приложения. В этом случае время, за- 
трачиваемое на динамическое приведение типов, постоянно, однако размер програм- 
мы резко возрастает, особенно, если в ней много классов. (Можно было бы сжать 
матрицу — тогда жизнь создателей компиляторов языка С++ стала бы намного легче.) 

Итак, оператор Яупатіс_саѕї значительно снижает производительность програм- 
мы, причем предсказать величину этого снижения невозможно. В некоторых случаях 
это оказывается совершенно неприемлемым. Следовательно, мы должны расширить 
нашу реализацию шаблона мі5ітог, чтобы адаптировать “циклический” шаблон 
\1$1%ог, предложенный группой Сов. Это позволит повысить быстродействие на- 
шего приложения, так как в “циклическом” шаблоне мі5ісог не используется дина- 
мическое приведение типов, хотя поддерживать его труднее. 

Работа шаблона Уіѕітог, предложенного группой СоЕ, уже описывалась в начале 
главы. Ниже перечисляются основные различия между “обычным” шаблоном \№1$1- 
тог и шаблоном Асус1іс міѕітог, реализованным в библиотеке Го. 


• Класс Ваземі5ітог больше не является фиктивным. В нем определяется одна 
чисто виртуальная функция-член мі5ітї для каждого инспектируемого типа (в 
предположении, что мы используем перегрузку функций). 
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» Функция дссертттр] должна измениться. В идеале макрос 
ОЕҒІМЕ_МІЅІТАВІЕ() остается неизменным. 


Все это сводится к следующему. У нас есть набор типов, подлежащих инспектиро- 
ванию: например, росЕЛетепї, Рагадгарй и Ваѕтегвіїтар. Как выразить этот набор 
типов и манипулировать с ним? Естественно в этот момент на ум приходят списки 
типов, описанные в главе 3. 

Списки типов — это именно то, что нам нужно. Мы хотим передавать список ти- 
пов шаблонному классу Сус11с\15$1Тог в качестве шаблонного параметра, как бы го- 
воря: “Я хочу, чтобы данный класс Сус1ісуіѕіїтог мог инспектировать данные ти- 
пы”. Сделать это можно следующим элегантным способом. 

// неполное объявление, необходимое для списка типов 

с1аѕѕ босЕТетепі; 

с1аѕѕ Рагадгарһ; 

с1аѕѕ Каѕїтегвіїтар; 


// инспектирует классы росЕТетепі, Рагадгарћ и Каѕтегвіттар 
хуредеї Сус11суїѕітог 
і 


усій, // Тип возвращаемого значения 
ТУРЕЕТ$Т_3 СросЕТемепї, Рагадгарһ, Казтегвттмар) 
> р 
мууї51Тоѓ; 
Класс Сус1ісуіѕіїтог зависит по имени от классов росЕЛетепї, Рагадгарћ и 
Каѕтегвіїтар. 
Посмотрим, какие дополнения нужно сделать в нашем коде. Используем про- 
цедуру, описанную в главе 9 при определении обобшенной реализации шаблона 
АБзітасі Касіогу. 


// Определение класса Ргімате: :Мі5ісогВіпдегв» 

// содержится в файле уіѕітог.һ 

сетр1ате «Турепате В, с1аѕ5 ТІі5 с» 

сТта55 СусТісмі5ітог : рибТіс Сбептѕсаїтегеаніегагсћу<тіїѕ?, 
ргімате::Мі5ісогВіпдегчВ»: :ВезиТ о» 


{ 
туреде{ к ветигитуре; 
тетр1ате <с1аѕ5 “уіѕїтеа> 
кетигптуре Уї511 (1 51теа& Но51) 
{ 
М151 тог<\М1 511е4>& 5иЬОБі = *1һіѕ; 
гесигп ѕиБоБј .М1$1 Е (Но$т); 
}; 


я 
Следует отметить, что класс Сус1ісміѕіїог использует класс Мі5іСсог в качестве 
строительного блока. Аналогичный способ был продемонстрирован в главе 3, а похо- 
жий пример был рассмотрен в главе 9 По сушеству, класс Сус1ісуїѕіїог наследует 
класс У15 1 їог«Т» для каждого типа Т, указанного в списке Ті і$ѕї. 

Если передать классу Сус1ісуіѕітог список типов, он завершит наследование от 
класса УЇ5і ог, конкретизированного для каждого типа, указанного в данном списке, 
объявив таким образом по одной чисто виртуальной функции Уіѕ1є для каждого ти- 
па. Иными словами, с функциональной точки зрения он эквивалентен базовому клас- 
су \151тог, как это предписывает шаблон міѕітог, предложенный группой СоБ. 
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После уточнения класса сус1ісміѕітог с помощью оператора туре4еф, скажем, 
классом Муміѕітог, нам остается лишь применить макрос 
ОЕЕІМЕ СУСІІС МІ5ІТАВІЕ(Мумі 5 і сог) в соответствующих инспектируемых классах. 


Туреде? СусТісуїзісог 
« 


уоїйд, // тип возвращаемого значения 

ТУРЕЕТ$Т_3 (ОосЕТетеп?, Рагадгарһ, Ваѕтегвітмар) 
> 
мум 51ітог; 


с1аѕ5 росЕТетепт 
{ 
рибТіс: 
мігтиа1 уоїд міз5іс(МУМі5ітогб) = 0; 
}; 
сТа55 Рагадгарһ : риб1іс росЕ1етепт 


рибііс: 

ОЕЕІМЕ СУСІІС МІ5ІТАВЦЕ(МуУі5 1 ог); 

у; 

Вот и все! Как и в классической реализации шаблона \1$1тог, предложенной 
группой СоЕ, нужно лишь быть дисциплинированным. Отличие заключается в том, 
что теперь вам придется держать в голове намного меньше информации. Для того 
чтобы сделать иерархию инспектируемой в рамках реализации “простого” шаблона 
уіѕітог, нужно выполнить следующие действия. 


® Сделать неполное объявление всех классов, входящих в иерархию. 


• Написать оператор туреде{Р для класса Сус1ісміѕітог, конкретизированного 
типом возвращаемого значения и списком инспектируемых типов. (Назовем 
этот класс Му\1$1тог.) 


• Определить в базовом классе чисто виртуальную функцию \1$1т+. 


• Добавить макрос ОЕРІМЕ СУСЦІС МІЗ5ІТАВІЕ(Мумі5ітог) в каждый класс ие- 
рархии или реализовать функцию Ассер* вручную. 


® Сделать каждый конкретный инспектор наследником класса Му\1 $1тог. 


• Обновлять конкретизацию шаблонного класса Мууіѕітог (оператор туредеР) 
каждый раз, когда в иерархию инспектируемых классов добавляется новый 
класс, и — увы! — компилировать ее снова. 


По сравнению с реализацией “обычного” шаблона мізісог обобщенный подход 
более понятен. Программисту нужно лишь самостоятельно определить класс 
Мум1 51 сог. 

С практической точки зрения лучше начинать с шаблона АсусТіс Ууїіѕітог, 
который легче поддерживать, а на шаблон Мізігог следует переходить лишь тогда, 
когда оптимизация становится действительно необходимой. Обобщенные компо- 
ненты позволяют легко экспериментировать — для этого нужно изменить лишь 
одно объявление. Остальной код остается без изменения. Детали реализации 
шаблона У151 сог хранятся в библиотеке. Нужно лишь наладить связь между кли- 
ентом и библиотекой, чтобы получить доступ к двум разным реализациям шабло- 
на уіѕітог. 


276 Часть ||. Компоненты 


10.6. Отладка вариантов 


Шаблон Ууіѕітсог имеет много вариантов и настроек. В этом разделе мы покажем, 
как его можно применять в собственных приложениях. 


10.6.1. Функция-ловушка 


Эта функция рассматривалась в разделе 10.2. Класс Ммі5ісог может столкнуться с 
неизвестным типом, производным от базового’ класса (например, классом 
росЕЛемепї). В этом случае либо компилятор выдаст сообщение об ошибке, либо во 
время выполнения программы будут произведены какие-то действия, предусмотрен- 
ные по умолчанию. 

Посмотрим, как решается эта проблема в реализациях шаблонов уіѕітог и Асу- 
сТісуї5і ог с помощью обобщенных компонентов. 

Для “обычного” шаблона уіѕітог ситуация проста. Если базовый класс вашей ие- 
рархии входит в список типов, передаваемых классу Сус1ісуіѕітог, существует воз- 
можность реализовать функцию-ловушку. В противном случае возникнет ошибка 
компиляции. Эти две возможности иллюстрируются следующим кодом. 

// неполные объявления, необходимые шаблону “обычному” Уїѕ1тог 

с1аѕ5 ОбоСЕТетепт; // Базовый класс 

с1аѕ5 Рагадгарһ; 


с1аѕ5 Каѕтегвіттар; 
с1аѕ55 МессогігейОгаміпд; 


Хуредеї Сус1ісуіѕітог 
< 


моїй, // тип возвращаемого значения 
ТҮРЕШІЅТ__ 3 (Рагадгарһ, Ка5сегВістар, МессогігейОгам'і пд) 
> 
5сгісітміз5ісог; // Операции перехвата не предусмотрены. 
// При попытке инспектирования неизвестного 
// типа возникает ошибка компиляции 
Туреде+ Сус1ісуіѕітог 


< 
моїа, // тип возвращаемого значения 
ТУРЕЦІ5Т. 4(росЕТептепі,Рагадгаріп, Ва5сегВіїтар, 
уессогігедргам'і пд) 
> 


моп5сгістмізісог; // объявляет функцию Уу151+(росЕТетепт&), 
// которая будет вызываться при попытке 
А // проинспектировать неизвестный тип 
Все это довольно просто. Теперь рассмотрим функцию-ловушку в обобщенной реали- 
зации шаблона Асус1іс Уїѕ1тог. 

Здесь применяется интересный прием. Хотя по существу перехват касается ин- 
спектирования неизвестного класса известным инспектором, проблема переворачива- 
ется: неизвестный инспектор инспектирует известный класс! 

Вернемся к реализации функции Ассерсттр для шаблона Асус1іс У151тог. 


тетр1ате <турепате в = \019> 
с1аѕ5 Вазеуї5ісабіе 


как и раньше 


тептрТаге <с1аѕ5 Т> 
зхасіс Кесигптуре дссерстир1 (тб: мі5ісед, Ваѕеуіѕітсог& диеѕї) 
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1Е (Мі5ісогеТь? р = ӣупатіс_саѕт<Уї51тог<т>*> (&9иеѕї)) 


гетигп р->\1$1т(\1$1те4); 
Рей ветигптуре(); // внимание! 
} А 

3; 

Допустим, мы добавляем в иерархию класса росЕ1етепт класс уестогіғергаміпд, ни- 
чего не сообщая об этом конкретным инспекторам. При попытке проинспектировать 
класс мессогігергаміпд динамическое приведение к типу “151 ог<уестогіғергаміпд> 
завершится аварийно, поскольку классу уіѕітог ничего не известно о классе Местогіге- 
ргаміпд. Следовательно, код активирует альтернативную процедуру и вернет значение ти- 
па Ветигптуре, предусмотренное по умолчанию. Именно в этом месте вступает в действие 
функция-ловушка. 

Поскольку наша функция Ассертттр1 содержит операцию гетигп Ветигптурес(), 
простора для вариаций не остается. Здесь следует применить стратегию перехвата. 

тетр1ате 

< 

Турепате А = уоїа. 
тетрТасе <турепате, сТа55» с1аѕ5 СатсһА11 = реҒаџ1тСатсһА11 
> 

сТа55 Ваѕеуіѕітаб1е 


{ 
как и раньше 
Тетр1ате <с1аѕѕ Т» 
Ѕтаїіс ветигптуре АссертїІтр1 Стё& мі5ісейд, Ваѕеуіѕітогё& диеѕї) 


1+ СУї5ѕ1ітог<Т>* р = дупатіс са5 С«У151 сог«т»ї» (8дие5 (22 


] гегигп р->Уіѕ1іїСуіѕітеа) ; 
// изменение 
гетигп Са®сһА11<А, Т>: :0пупКкпомпмї51сог(мі5ітейд, диеѕт); 
} | 
У; 
Стратегия СапсһА11 вполне соответствует требованиям шаблона. Она может воз- 
вращать значение по умолчанию или код ошибки, генерировать исключительную си- 
туацию, вызывать виртуальную функцию-член для инспектируемого объекта, пытать- 
ся выполнять динамическое приведение типов и т.д. Реализация функции опупКпомт- 
уіѕітог значительно зависит от нужд конкретного приложения. В некоторых случаях 
необходимо, чтобы инспектирование было выполнено для всех типов, входящих в ие- 
рархию. В других случаях это относится лишь к некоторым типам, а остальные можно 
проигнорировать. В реализации шаблона АсусТіс УМі5ісог в основном применяется 
второй подход, поэтому по умолчанию стратегия СатсПАЛ1 имеет следующий вид. 


тетр1ате «сТа55 В, сТа55 Мі5ісей» 
ѕтгист реҒац1 тСатєсһА1Ї 


Ѕѕтаїтіс в опипКпомпУі5ітог (У1$1те4&, Ваѕеуіѕітогё) 
// Здесь указываются действия, которые следует 


// предпринять при несоответствии между инспектором и 
// и инспектируемым объектом. Обычно должно 
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// возвращаться значение, заданное по умолчанию 
гесигп КО; 
} 
}; 
Если нужно, чтобы выполнялись другие действия, достаточно заменить шаблон в 
классе ВаѕеуіѕітаБ1е. 


10.6.2. Нестрогое инспектирование 

Любой программист хотел бы иметь быстрые, независимые и гибкие инспек- 
торы, способные читать его мысли и отличать обычную ошибку от вынужденного 
решения. С другой стороны, программисты — люди практичные, и с ними можно 
договориться. 

Гибкость стратегии СатсһА11 вызывает зависть у пользователей шаблона уіѕітог, 
прелложенного группой СоЕ. Реализация этого шаблона весьма строга — она объяв- 
ляет одну чисто виртуальную функцию для каждого инспектируемого типа. Каждую 
перегрузку функции уіѕіх нужно выводить из класса Ваѕеуіѕітог и реализовывать 
отдельно. Если это не сделать, код не будет компилироваться. 

Однако иногда инспектировать все типы, указанные в списке, совершенно не обя- 
зательно. Программисты хотят иметь выбор: либо реализовывать функцию \1$1е для 
каждого типа, либо автоматически вызывать функцию Опупкпомпуіѕ1іӯог для собст- 
венной реализации стратегии СатсһА11. 

Для таких ситуаций библиотека [101 предусматривает класс ВаѕеміѕіїогІтр]. Он 
является производным от класса Ваѕеуіѕітог и использует адаптированные списки 
типов. Его реализацию можно найти в библиотеке ГоК! (файл Уіѕ1ітог.һ). 


10.7. Резюме 


В главе обсуждался шаблон \У1$1тог и связанные с ним проблемы. По существу, 
шаблон Уіѕітог позволяет добавлять виртуальные функции в иерархию классов без 
модификации этих классов. В некоторых случаях шаблон Уіѕіїог позволяет делать 
программы более ясными и гибкими. 

Однако с шаблоном Уіѕітог связано много проблем. Дело в том, что его можно 
применять лишь для очень устойчивых иерархий классов, для остальных иерархий это 
сделать практически невозможно. В этом случае можно воспользоваться шаблоном 
АСУуСТіс У1Т51тог, пожертвовав эффективностью приложения. 

Используя тщательно продуманные и сложные приемы, можно создать обобщен- 
ную реализацию шаблона Уіѕітог. Сохраняя практически все преимущества шаблона 
уіѕітог, его обобщенная реализация позволяет избежать многих проблем. 

В конкретных приложениях может оказаться полезным шаблон Асус1іс \151+ог, 
правда, за счет снижения быстродействия программы. Если скорость работы прило- 
жения очень важна, следует использовать обобщенную реализацию шаблона МТ51ТЪог, 

облегчающую поддержку приложения нужно контролировать только длин класс) И ке 

замедляющую компиляцию. 
Обобщенная реализация использует самые совершенные приемы программи- 
р о 
Я ляется возможность выделить наи- 


более общие и повторяющиеся части реализации шаблона У1$1хог в отдельную 
библиотеку. і 
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10.8. Краткий обзор обобщенных компонентов 
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шаблона \М!5Ког 


Для реализации шаблона Асус11с \У151тог используются классы Вазе\1$1тог 
(в качестве фиктивного базового класса), уіѕітог и уіѕітађ1е. 
с1аѕѕ Ва5еміз5ігог; 


хетріате <с1аѕ5 Т, турепате А = усій» 
с1аѕ5 №151тог; 


тетр1атсе 
< 
хурепате в = \014, 
тетрТасе«сТаз55, с1аѕѕ> СаёсһА11 = РеФаи]тСафсНА11 
» 
сТа55 Ваземіз5ітабТе; 


Первый шаблонный параметр классов Уіѕіїог и Ваз5емі5і ог задает тип зна- 
чений, возврашаемых функциями-членами уіѕії и дссерт, соответственно. По 
умолчанию это — тип \014 (как в большинстве примеров, приведенных в книге 
СоЕ (2000), и описаний шаблона М1 $1 бог). 


Вторым шаблонным параметром класса ва5емізітабЛе является стратегия пе- 
рехвата (раздел 10.2). 


Основу инспектирусмой иерархии следует выводить из класса Вазе\1 $1 сабТе. За- 
тем следует применять макрос ОЕРЕІМЕ МІ5ІТАВІЕ О) в каждом классе иерархии или 
предусмотреть собственную реализацию функции дссер* (Ваземіз і сог56). 


Конкретные инспектирующие классы следует выводить из класса Вазе\1 $1*ог. 
Кроме того, их можно выводить из класса уіѕітсог<т> для каждого инспекти- 
руемого типа Т. 


Для “обычного” шаблона У1$1тог следует применять шаблонный класс Су- 
сТісмізісог: | 

хетріасе «Сурепате В, с1аѕ5 ТІ ї5і» 

сТа55 Сус1ісуіѕ1сог; 
Инспектируемые типы нужно указывать в шаблонном аргументе ТІЇ 57. 


Класс Сус1ісуіѕісог можно использовать наравне с классическим классом 
№151 тог. 


Если нужно реализовать лишь отдельную часть шаблона уіѕітог (нестрогий 
вариант), инспектируемую иерархию следует выводить из класса Вазе\1$1- 
тогттр1. Этот класс реализует все перегрузки функции №1511, необходимые 
для вызова функции опупкпомп\У1$1тог. Часть этого класса можно замешать 
собственными функциями. 
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МУЛЬТИМЕТОДЫ 


В этой главе определяются, обсуждаются и реализуются мультиметоды в контексте 
языка С++. 

Механизм виртуальных функций в языке С++ позволяет производить диспетчери- 
зацию вызова в зависимости от динамического типа объекта. Мультиметоды предна- 
значены для диспетчеризации вызова функции в зависимости от типов нескольких 
объектов. Для универсальной реализации языка необходима специальная поддержка. 
Именно так осуществляется реализация языков СГ.О$, МГ, Назке!! и Руап. Однако в 
языке С++ такой поддержки нет, поэтому его эмуляция остается в компетенции раз- 
работчиков библиотек. 
| В главе обсуждаются типичные решения и некоторые обобщенные реализации ка- 
ждого из них. Эти решения представляют собой разные компромиссы между быстро- 
действием, гибкостью и управлением зависимостями. Чтобы описать способ диспет- 
черизации вызова функции в зависимости от нескольких объектов, мы используем 
термин мультиметод (тиїштегодй), позаимствованный у языка СІО5, и множествен- 
ная диспетчеризация (ти@р!е діѕраісһ). В частности, множественная диспетчеризация 
для двух объектов называется двойной диспетчеризацией (ЗоцЫе аіѕраїсћ). 

Реализация мультиметодов — это чрезвычайно сложная и увлекательная задача, 
лишившая сна и покоя многих разработчиков и программистов.! 

В главе рассматриваются следующие вопросы, 


. Определениє мультиметодов, 


• Идентификация ситуаций, в которых необходимо применять полиморфизм 
мультиобъектов. 


• Обсуждение и реализация трех двойных диспетчеров, представляющих вопло- 
щения разных компромиссов. | 


• Усовершенствование механизма двойной диспетчеризации. 


Прочитав эту главу, вы легко справитесь с типичными ситуациями, вынуждающи- 
ми применять мультиметоды. Кроме того, вы сможете использовать и расширять не- 
которые надежные обобщенные компоненты, предоставленные библиотекой ГоК, ко- 
торые реализуют мультиметоды. 

Мы ограничимся обсуждением мультиметодов для двух объектов (двойная диспет- 
черизация). Овладев этой методикой, вы сможете самостоятельно распространить ее 


! Если вам не удастся реализовать мультиметоды, рассматривайте эту главу в качестве сно- 
творного средства, хотя я надеюсь, что она не обладает усыпляющим эффектом. 


на любое количество объектов. Однако в большинстве ситуаций можно обойтись 
двойной диспетчеризацией, непосредственно воспользовавшись библиотекой [окКі. 


11.1. Что такое мультиметоды? 


В языке С++ полиморфизм, по существу, означает, что вызов данной функции связан 
с разными реализациями и зависит от статического или динамического контекста. 
В языке С++ реализованы два типа полиморфизма. 


® Статический полиморфизм (сотрйе-Ите роіутогрһіѕт), осуществляемый с по- 
мощью перегрузки и шаблонных функций.? 


• Динамический полиморфизм (гип-іте роіутогрћіѕт)м, реализуемый виртуаль- 
ными функциями. 


Перегрузка — это простой вид полиморфизма, позволяющий нескольким одно- 
именным функциям существовать в одной и той же области видимости. Если эти 
функции имеют разные списки параметров, компилятор может различать их во время 
компиляции. Перегрузка представляет собой удобную синтаксическую конструкцию, 
позволяющую сократить текст программы. 

Шаблонные функции являются основой статического механизма диспетчеризации. 
Они осуществляют более сложный статический полиморфизм. 

Имя виртуальной функции связывается с се конкретной реализацией во время вы- 
полнения программы в зависимости от динамического типа объекта, к которому она 
применяется. 

Посмотрим, как масштабируются эти три вида полиморфизма для нескольких объ- 
ектов. Для перегруженных и шаблонных функций это происходит вполне естественно. 
Оба механизма допускают использование нескольких параметров, а выбор функции 
производится на основе запутанных статических правил. 

К сожалению, виртуальные функции — единственный механизм, реализующий 
динамический полиморфизм в языке С++, — могут работать только с одним объек- 
том. Даже синтаксис вызова виртуальной функции — оБј.Еип(аргументы) — отдает 
предпочтение объекту обі перед аргументами. (Фактически объект обі) является лишь 
одним из аргументов функции Ейп, доступ к которому осушествляется с помощью 
указателя *%Н15. В языке ОУап, например, оператор “точка” является лишь одним из 
многих конкретных воплощений общего механизма вызова функции.) 

Мы будем называть мультиметодами, или множественной диспетчеризацией, механизм, 
связывающий вызов с разными конкретными функциями в зависимости от динамических 
типов нескольких объектов, участвующих в вызове. Поскольку статический мультиобъект- 
ный полиморфизм уже существует, остается только реализовать его динамический аналог. 


11.2. Когда нужны мультиметоды 


Определить, когда следует использовать мультиметоды, очень просто. Допустим, в 
программе есть операция, манипулирующая несколькими полиморфными объектами 


2 Автоматическое преобразование типов можно было бы квалифицировать как простейший вид 
полиморфизма, поскольку оно, например, позволяет вызывать функцию 51м: :51йӣ с параметром, 
имеющим тип Тпх, хотя изначально параметр этой функции имеет тип доші е. Однако это мнимый 

‚ полиморфизм, поскольку к параметрам обоих типов применяется одна и та же функция. 
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с помощью указателей или ссылок на их базовые классы. Необходимо модифициро- 
вать операцию в соответствии с динамическими типами этих объектов. 

Столкновения (соЦізіоп5) представляют собой типичную категорию проблем, кото- 
рые лучше всего решать с помощью мультиметодов. Предположим, что мы разрабаты- 
ваем видеоигру, в которой движущиеся объекты выводятся из абстрактного класса 
Сатеобіесс. Нам хотелось бы, чтобы их столкновение зависело от типов сталкиваю- 
щихся объектов: космического корабля с астероидом, корабля с космической станци- 
ей или астероида со станцией.3 

Допустим, что мы хотим ‘выделять области перекрытия двух нарисованных объектов. 
Напишем программу для рисования, позволяющую пользователю определять прямоуголь- 
ники, круги, зллипсь, многоугольники и другие фигуры. В основу разработки положим 
классический объектно-ориентированный подход: определим абстрактный класс $Варе и 
выведем все конкретные фигуры из него. Затем будем управлять рисованием с помошью 
набора указателей на объекты, производных от класса ѕћаре. 

Тут к нам подходит клиент и просит предусмотреть следующее: если две фигуры 
пересекутся, область их пересечения нужно нарисовать иначе, чем сами фигуры, на- 
пример, заштриховать (рис. 11.1). | 


Рис. 11.1. Штриховка пересечения двух фигур 


Разработать один алгоритм, заштриховывающий любое Пересечение, сложно. На- 
пример, алгоритм для штриховки пересечения эллипса и прямоугольника намного 
сложнее, чем алгоритм для штриховки пересечения двух прямоугольников. Кроме 
того, чрезмерно общий алгоритм (например, на уровне работы с пикселями) будет 
слишком неэффективен, поскольку некоторые пересечения (скажем, двух прямо- 
угольников} тривиальны. 

Здесь нужен набор алгоритмов, специализированных для каждой пары фигур, на- 
пример, прямоугольник-прямоугольник, прямоугольник-многоугольник, многоуголь- 
ник-многоугольник, эллипс-многоугольник и эллипс-эллипс. В ходе выполнения 
программы, когда пользователь перемещает фигуры по экрану, нужно выбрать пра- 
вильный алгоритм, который бы закрашивал пересечение фигур достаточно быстро. 

Поскольку манипуляции фигурами осуществляются с помошью указателей на 
класс 5Наре, у нас нет информации о типах объектов, позволяющей выбирать нужный 
алгоритм. Придется работать только с указателями на класс ѕћаре. Поскольку в каж- 
дом пересечении участвуют два объекта, простые виртуальные функции не решат на- 
шу задачу. Следует применить двойную диспетчеризацию. 


5 Этот пример и имена позаимствованы из книги Скотта Мейерса “Моге ЕЙесиуе С++” 
(1996а), задача 31. 
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11.3. Двойное переключение по типу: грубый подход 


Проще всего реализовать двойную диспетчеризацию на основе двойного переклю- 
чения по типу (доиЫе змисИ-оп-буре). Для этого нужно попытаться последовательно 
выполнить динамическое приведение типа первого объекта к каждому из типов объ- 
ектов, которые могут стоять в левой части выражения. Для каждой ветви нужно сде- 
лать то же самое со вторым аргументом. После обнаружения типов для обоих объек- 
тов становится ясно, какую функцию следует вызвать. 


// Разные алгоритмы закраски пересечения фигур 
уо14 ронаїсһдгеа1 (кессапо1е&, Кестапо1е&) ; 
уоіа ронатсһдгеа2 (КВестапд1е&, Е111рѕеё&) ; 

уоїіа ронатсһдгеа3 (кестапд]е&, Ро1у&) ; 

уоіа ронатсћАгеа4 (Е111рѕе&, Ро1у&) ; 

уоіа ронатсһдгеаѕ (Е11їрѕе&, Е111рѕе&) ; 

уоїа ронатсһАгеаб (Ро1у&, РОТув); 


уоіа роџиЬ1еріѕратсћ(Сѕһаре& 1Н5, $Паре& “һҺѕ) 


{ 5 
1Ғ Скестапд1е* рі = дупатіс са5 «КестапдТет» (&1һ5)) 
1 


1Ғ (Кестапд1е* р2 = дупатіс_саѕі<кессапд1е*> (аг 5)) 
ронаїтсһдгеа1(*р1, *р2); 

е1ѕе 1Р (Е111ірѕе р2 = Пупатіс_саѕт<Е11ірѕе*> (&гһѕ)) 
ронатсһдАгеа2 (*р1, *р2); 

е15е 15 (РоОТу р? = дупатіс_саѕє<Ро1у*> (&гһћѕ)) 
ронаїсһАгеа3 (*р1, *р2); 

е15е 
Еггог("неопределенное пересечение") ; 


} 
е1ѕе 1+ (Е11ірѕе* рі = дупатіс_саѕт<Е111рѕе*> (&1һ5)) 


1Ғ (Аестапд1е* р2 = даупапіс._саѕї<Кестапд1е*> (&гһѕ)) 
ронатсһдгеа2 (*р2, *р1); 

еї5е 1ЁҒ (Е111ірѕе р2 = дупатіс_саѕт<Е111рѕе*> (&гһћѕ)) 
ронатсһдгеа5 (*р1, *р2); 

е]5е 1Ғ (Ро]у р2 = дупатіс саз5 с«РОТу"» (&гћѕ)) 
ронатсНнАгеа4 (*р1, *р2); 

е15е 
ЕГГОГ("Неопределенное пересечение“); 


} 
е]5е 14 (РоТу* рі = дупатіс саз5«РОТу") С&1ћ5)) 
1 


1Р (ВессапдТе" р2 = дупатіс, са5 схВессапдї ет» (&гћѕ)) 
ронатсНАгеа2 (*р2, *р1); 

е1ѕе 1Ғ (Е11ірѕе р2 = дупатіс_саѕї<Е11ірѕе*> (&гһѕ)) 
ронатсһАгеа4 (*р2, *р1) ; 

е15е іҒ (РОТу р? = дупатіс са5 с«РОТу»» (&гһѕ)) 
ронаїсһдгеаб(*р1, *р2); 

е15е 
ЕГГОГ ("Неопределенное пересечение"); 


е1ѕе 


{ 


ЕГГОГ("Неопределенное пересечение"); 
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Надо же! Оказалось, достаточно нескольких строк. Очевидно, что подобный гру- 
бый подход вынуждает нас писать большое количество внешне тривиальных кодов. 
Такую паутину из условных операторов может сплести любой программист. Кроме 
того, это решение оказывается достаточно эффективным, если количество классов не 
слишком велико. Функция роиђБ1еріѕраїсћһ выполняет линейный поиск во множестве 
возможных типов. Поскольку поиск разворачивается (программа содержит последова- 
тельность операторов 15-е15е, а не цикл), для небольших множеств алгоритм будет 
работать достаточно быстро. 

Грубый подход порождает неприемлемый размер программы. При большом коли- 
честве классов программу становится невозможно поддерживать. Приведенный выше 
код работает лишь с тремя классами, но уже имеет значительный размер. С увеличе- 
нием количества классов размер кода возрастает по экспоненциальному закону. Пред- 
ставьте себе эту программу, если иерархия состоит из 20 классов! 

Вторая проблема заключается в том, что реализация функции ОоціЛерізратсі 
должна иметь информацию о существовании всех классов, входящих в иерархию. 

Третий недостаток функции роиБ1еріѕратсћ заключается в том, что порядок сле- 
дования операторов 1+ имеет большое значение. Это очень сложная и опасная про- 
блема. Вообразите, например, что из класса Вестапде выводится класс Коипаедвес- 
хапдїє (прямоугольник с закругленными углами). Мы редактируем функцию бои Ле- 
ріѕратсћһ, вставляя дополнительные операторы 1+ в конец каждого оператора 15- 
е15е, непосредственно перед вызовом функции Еггог. Вот и ошибка! 

Если функции роиБ1еріѕраїсһ передается указатель на класс Коипеавесќапд1е, 
оператор дупатіс_саѕїт<Кестапд1е*> выполняется успешно. Поскольку эта проверка 
выполняется до проверки аупатіс_саѕт<Коипаедћестапд1е*>, первая проверка 
“проглотит” и класс Весїапд1е, и класс Воип4едвесталд]е. Вторая проверка стано- 
вится излишней. Большинство компиляторов это совершенно не волнует. 

Эти проверки следует немного изменить. 


уоїд роиБ1еріѕратсһ(ѕһаре& 11$, Ѕһаре& гһѕ) 


{ 
1# (туреіа(1һѕ) == туреіа(кестапд1е)) 
{ 
Кестапд1е* рі = дупатіс__саѕї<Кесїтапд1е*> (&1һ5) ; 
} 
е1ѕе 
} 


Теперь проверка выполняется только для точного типа, а не для точного или произ- 
водного. Сравнение туреїа выдаст отрицательный результат, если указатель 105 ссы- 
лается на объект класса Аоипаейкестапд1е, поэтому проверки будут продолжены. В 
итоге проверка гуреї д(Ккоипаеавестапоїе) будет выполнена успешно. 

Увы, исправляя один недостаток, мы создаем другой: функция роџиб1еріѕраїсћ стано- 
вится слишком жесткой. Если в ней не предусмотрен какой-нибудь тип, естественно ожи- 
дать, что функция роиб1еріѕратсћ сработает на ближайшем к нему базовом типе. Именно 
на это мы обычно рассчитываем — по умолчанию производные объекты представляют со- 
бой базовые объекты, за исключением некоторых замещенных свойств. Проблема заклю- 
чается в том, что реализация функции роиБ1еріѕратсћ на основе оператора туреїа этой 
возможностью не обладает. Отсюда следует, что в функции роиб1еріѕраїсһћ нужно по- 
прежнему использовать оператор аупалті с..саз* и упорядочить проверки 15, чтобы наибо- 
лее далекие потомки базового класса обрабатывались первыми. 
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Так возникают еще два недостатка грубого подхода к реализациям мультиметодов 
Во-первых, зависимость функции роиБ1ері ѕратсћ от иерархии класса $Наре увеличи- 
вается — функция должна знать не только о существовании классов, но и: об их взаи- 
моотношениях. Во-вторых, поддержка соответствующей систематизации динамиче- 
ских приведений типов связана с дополнительной нагрузкой. 


11.4. Автоматизированный грубый подход 


Поскольку в некоторых ситуациях быстродействие грубого подхода оказывается 
непревзойденным, имеет смысл реализовать такой диспетчер. 

Напомним, что в библиотеке [о определены списки типов — наборы структур и 
статических алгоритмов, позволяющих манипулировать коллекциями типов. Грубая 
реализация мультиметодов может использовать предоставленный пользователем спи- 
сок типов, в котором перечислены классы, входящие в иерархию (в нашем примере — 
классы Кестапд1е, Ро1у, Е11ірѕе и др.). Затем рекурсивный шаблон может генериро- 
вать последовательность операторов 1+-е15е. 

В общем случае мы можем работать с разными коллекциями типов, поэтому список 
типов для левого операнда может отличаться от списка типов для правого операнда. 

Попробуем набросать шаблонный класс 5хасісбрізратсНнег, выполняющий алго- 
ритм вывода типов и вызывающий функцию из другого класса. 

тетрТате 

< 

с1аз5 Ехеситог, 

с1аѕѕ Ваѕегһѕ, 

с1аѕ5 Туреці5, 

с1аѕ5 Ваѕекһѕ = Ваѕегһѕ, 

с1аѕѕ Туреѕаһѕ = Туреѕіһѕ, 

Турепате Кеѕи1+Туре = уоїа 
> 

сТба55 ѕЅїатісріѕраїсһћег 


{ 
Туреде+ турепате Туреѕіһѕ: :Неаа Неаа; 
Туреде{ турепате Туреѕһѕ: :Таї1 Таї1; 
риб'їс: 
ЅТаїтіс ВезиїсТуре со(ва5еці56, ваѕекһѕ&, 
Ехеситсог ехес) 


1+ (Неаа* рі = дупат1с_сазт<Неаа*> (&1һѕ)) 


{ 
гесигп Ѕтатісріѕратсһег<Ехеситог, Ваѕеһѕ, 
ми11туре, ваѕекћѕ, Туреѕвһѕ> : : 01 5рассивИ$ ( 
*р1, "һѕ, ехес); 
} 
е1ѕе 
{ А 
гетигп Ѕїтатісріѕратсһег<Ехеситог, Ваѕегһѕ, 
Таі1, Ваѕекһѕ, ТуреѕАһѕ> : :60( 
і 1Н$, гһѕ, ехес); 
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Класс таЕ1с01зраесвег устроен довольно просто. Учитывая сложность задачи, кото- 
рую он решает, размер его кода удивительно мал. 

Класс 5сасісрізрасспег имеет шесть шаблонных параметров. Класс Ехесиїог — эти 
тип объекта, выполняющего реальную работу, — в нашем примере он закрашивает область 
пересечения фигур. Его внутреннее устройство мы рассмотрим немного позднее. 

Классы Ваѕегһѕ и вазевН$ представляют собой базовые типы аргументов левого и 
правого операндов соответственно. Классы Туреіһѕ и ТуревН$ — это списки типов, 
состоящие из возможных производных классов для этих двух аргументов. По умолча- 
нию классы вазевИ$ и Туреѕвһѕ реализуют диспетчер для типов, входящих в одну и 
ту же иерархию, как в программе для рисования. | 

Класс вези1ттуре — это тип результата двойной диспетчеризации. В общем случае вы- 
зываемая функция может возвращать произвольный тип. Класс 5сасісрізрасспег под- 
держивает такую степень обобщенности и возвращает результат вызывающему модулю. 

Функция ѕїаїісріѕратсһег: :бо выполняет динамическое приведение адреса 1Н$ 
к первому типу, указанному в списке Туре5іН5. Если динамическое приведение ока- 
залось невыполнимым, функция Со передает хвост списка Туреѕі һѕ своему рекурсив- 
ному вызову. (На самом деле это не настоящий рекурсивный вызов, поскольку каж- 
дый раз производится новая конкретизация класса 5татісріѕратсћег.) 

В итоге функция Со выполняет подходящий оператор 1і#-е1ѕе, применяющий 
оператор аупатіс _саѕт к каждому типу, указанному в списке. Обнаружив соответст- 
вие, функция бо вызывает функцию рбіѕраїсһаһѕ. Это второй и последний этап вы- 
вода типа — обнаружение динамического типа объекта гИ$, 


Тетр1ате <...> 
с1аѕ5 $+аф1с015ратспег 


.г как и раньше ... 
тетрТасе <с1аѕ5 З5отецП5» 

зсасіс ВезиТстТуре Оізрасспвн5 (5отеїП5б 1Н$, Ваѕевһѕ& гһѕ, 
| Ехесисог ехес) 


туредеї сурепате ТурезАН5::неай неаа; 
хуредеї турепате Турез5ЕН5::Таї1) Таї1; 


ЇҒ (неаа* р2 = дупатіс са5 с«Неад'» (&гһѕ)) 
гетигп ехес.ЕїгеС1һѕ, *р2); 


е1ѕе 


і гетигп 5тасісрізраєспег«Ехеситог, 5отецН58, 
ми11туре, ваѕевһѕ, таї1»::Оїз5расспвН5 ( 
Тн$, гИ$, ехес); 
} 
} 

$; 

Функция ріѕратсһаһћѕ выполняет для объекта гћѕ тот же алгоритм, который приме- 
нялся функцией Со для объекта 115. Кроме того, если динамическое приведение типа гИ$ 
выполнено успешно, функция ріѕраєсһаһѕ вызывает функцию. Ехеситог::Еіге, переда- 
вая ему два определенных типа. Как и прежде, код, генерируемый компилятором, пред- 
ставляет собой набор операторов 15-е15е. Интересно, что компилятор генерирует для ка- 
ждого типа, указанного в списке Туреѕ_һѕ, отдельный набор операторов 15-е15е, Дейст- 
вительно, класс $Та1с015ратсНег порождает экспоненциальный объем кода, имея два 
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списка типов и фиксированный базовый код. Это ценное, однако потенциально опасное 
качество — слишком большой код может потребовать слишком много времени на этапе 
компиляции, негативно повлиять на размер программы и общее время ее выполнения. 

Для того чтобы установить ограничения на статическую рекурсию, нам нужно спе- 
циализировать класс $тат1со15ратспег для двух ситуаций, когда тип. объекта 1Н$ в 
списке Туреѕһѕ и тип объекта гһѕ в списке Туре5ЕН5 не найдены. 

Первая ситуация (неверный объект 115) возникает при вызове функции бо из класса 
зсасісрізраєссНег, когда в качестве параметра Туреѕ_151 ему передается класс ми11туре. 
Это признак того, что во время поиска список Туреѕ_һѕ оказался исчерпанным. 
(Напомним, что класс ми11Туре используется в качестве признака конца списка типов.) 

тетрТате 

< 

с1аѕѕ Ехеситог, 
с1аѕ5 Ваѕегһѕ, 
с1аѕѕ Ваѕевһѕ, 
с1аѕѕ ТурезАН5, 
турепате Веѕи1+Туре 
> 
с1а$$ $+а+1с015ратсНег<Ехесифог, Ваѕегһѕ, МиТітуре, 
Ваѕекһѕ, ТурезвН$, кези]ттуре> 


зсасіс моїй бо(Вазей$& 115, Вазевн$@& гһѕ, Ехеситог ехес) 


ехес.ОПЕГГОГ(ЛН5, ГИ$); 


у; 
Обработка ошибок элегантно делегируется классу Ехесифог, который будет рассмот- 
рен ниже. 5 

Вторая ситуация (неверный объект гі5) возникает при вызове функции 01$- 
раїсһАһѕ из класса 5сасісрізрассНнег, когда в качестве параметра ТурезвН$ ему пе- 
редается класс Ми11Туре. 


темр1ате 
< 


сТа55 Ехеситог, 

с1а55 Ва5еці5, М 
с1аѕѕ Туреѕіһѕ, 

с1аѕ5 ваѕевһѕ, 

с1аѕ5 Туреѕвһѕ, 

хурепате Кеѕџ1 туре 


х 
сТа55 Ѕїтатісріѕратсһег<Ехеситог, Ваѕегһѕ, Туреѕіһѕ, 
Ваѕекһѕ, №и117туре, Кеѕи1+туре> 


{ 
риБ11с: 
5зхасіс моїй ріѕратсһаһѕ (Ваѕегһѕ& 1һ5, Вазевн$& гИ$, 
Ехеситогё@ ехес) 


ехес.ОпЕГггог(\ћѕ, гһћ5); 


}; 

Теперь настало время обсудить, как нужно реализовать класс Ехеситог, чтобы ис- 
пользовать преимущество механизма двойной диспетчеризации, определенного выше. 

Класс 5хасісрізрасспег лишь распознает типы. Обнаружив правильные типы и 
объекты, он передает их функции Ехеситоѓ::Ғіге. Чтобы различать вызовы этой 
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функции, класс Ехеситог должен реализовать несколько перегрузок функции Еїге. 
Например, класс Ехеситог для закрашивания области пересечения двух фигур выгля- 
дит следующим образом. 

с1аз$ НатсИ1пдЕхесиког 


{ 
риБ1іс: 
// Разные алгоритмы закрашивания области пересечения 
уоїа Еіїге(Вестапдїеб, кесхапд1е&); 
уоїа Еі ге(Аессапо1е&, Е111їрѕеё) ; 
уоїд Ғ1ї ге (Кессапо1е&, Ро1у&) ; 
уоїа Еі ге(Е111ірѕеё&, Ро1уё&) ; 
уоїа Еі ге(Е111рѕе&, Е11ірѕе&) ; 
\014 Еїге(РОТуб, Ро1у&) ; 


// Функция для обработки ошибок 
моїй ОпЕггог($Варе&, Ѕһаре&) ; 


ЕД 
Класс натсһі пдЕхеситог используется вместе с классом 5хасісрізрасспег 
хуредеї ѕтатісріѕраёсһег<НатсһіпсдЕхеситог, Ѕһаре, 
ТҮРЕШІЅТ__ З СкестапаТе, Е111ірѕе, РОТу)» ріѕраїсһег; 

Ѕһаре *р1 = ...; 

Ѕһаре *р2 = ...; 

Натсһїі пдЕхеситог ехес; 

ріѕратсћһег: :Сбо(*р1, *р2, ехес); 

Этот код вызывает соответствуюшую перегрузку функции Ғіге из класса 
насспіпдехесисог. Шаблонный класс Ѕїаїісрїіѕраїсһег можно рассматривать как меха- 
низм динамической перегрузки — он откладывает перегрузку на период выполнения про- 
граммы. Это значительно облегчает использование класса ѕтатісріѕратсһег. Нужно лишь 
реализовать класс насспіпдЕхеситог, имея в виду правила перегрузки, а затем использо- 
вать класс Ѕасісріѕратсһег в качестве черного ящика, применяющего правила перегруз- 
ки во время выполнения программы. 

Класс ${ат1с015ратсНег имеет побочный эффект — он распознает и перегружает 
неоднозначности на этапе компиляции. Допустим, что мы вместо функции натсһ- 
1пдЕхеситог: : ЕТге(Е111р5е&, РОТуб) объявили функцию натсһіпдЕхеси- 
тог::Еїге(5Пареб, Ро1у&). Вызов функции НаїсһіпдЕхесиїоѓ: : Ғі ге с параметрами 
типа Е111рѕе и РОТу может породить неоднозначность — обе функции соответствуют 
одному и тому же вызову. Интересно, что класс Ѕтатісріѕраїсһег также обнаружи- 
вает эту ошибку и выдает о ней такое же детальное сообщение. Класс Ѕїаїісріѕ- 
ратсһег полностью соответствует правилам перегрузки, существующим в языке С++. 

Что случится, если во время выполнения программы обнаружится ошибка — на- 
пример, если в качестве одного из аргументов функции Ѕїаїісріѕраїсћег: :Со пере- 
дать класс СігсТе? Как уже упоминалось, в таких ситуациях класс ѕїтаїісріѕратсһег 
просто вызывает функцию Ехесисог::ОпЕггог, параметрами которой являются ис- 
ходные (не преобразованные) объекты 1һѕ и гһѕ. Это значит, что в нашем примере 
функция натсһіпдЕхеси?тог: :ОПЕГГОГ (Ѕһаре&, Ѕһаре&) представляет собой модуль 
обработки ошибок. Эту функцию можно применять по своему усмотрению — ее вы- 
зов означает, что класс 5тат1с01 ѕратсһег приступает к поиску динамических типов. 

«Как указывалось в предыдушем разделе, при грубой реализации диспетчера насле- 
дование порождает новые проблемы. Следовательно, приведенная ниже конкретиза- 
ция класса Ѕ5таїісріѕраїсһег содержит ошибку. 
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Турефеї Ѕтатсісріѕраїсһег 
« 


5отеєхесисог, 
паре, 
ТУРЕЕТ$Т_4 (Кессапо1е, Е111ірѕе, РОТу, коипаейкессапо1е) 


> 
Муріѕратсћһег; 

Если шаблонному классу МурізрайсНнег передается класс Коипаедвестапд1е, он будет 

рассматриваться как класс вестапд1е. Оператор дупатіс са5'є«вВестапдПїех» успеш- 

но применяется к указателю на класс воип4едвестапд]е, а поскольку оператор 

аупатіс__саѕ<поипаеавестапд1е*> находится в цепочке проверок ниже, он никогда 

не будет выполнен. Правильная конкретизация выглядит следующим образом. 


Туреде{ Ѕтатісріѕратсһег 


< 

ЅотеЕхеситог, 

Ѕһаре, 

ТУРЕТТЬТ_4 (поџипаеакесёапо1е, Е111рѕе, Ро1у, Кестапд1е) 
> 
різраєспег; 


Общее правило таково: наиболее отдаленные потомки базового типа должны. нахо- 
диться в начале списка типов. 

Было бы прекрасно, если бы это преобразование выполнялось автоматически. 
Списки типов позволяют это сделать. У нас есть средство для обнаружения. наследо- 
вания во время компиляции (глава 2), причем списки типов можно упорядочить. Та- 
ким образом, можно воспользоваться статическим алгоритмом бегі уеЧторгопт, опи- 
санньм в главе 3. 

Для автоматической сортировки списка нужно лишь модифицировать реализацию 
класса 5сагісрізраєспег следующим образом. 


тетр1ате <...> 
сТа55 Ѕ%№атісріѕраїёсһег 


Турейе#Ғ сурепате Оегіуедтовгопі« 
Турепате Туре! И$ : :Неад> : : кези]т неаа; 
хуредеї фурепаме регімедтовгопі« 
турепате туреѕіһѕ: :та11>: : Вези1т Таї1; 
риб11с: 
} .. как и раньше ... 


Обеспечив удобную автоматизацию, не забудьте, что мы получаем в результате 
программу, генерируюшую код. Проблема, связанная с существованием зависимостей 
между классами, остается нерешенной. Несмотря на то что грубую реализацию муль- 
тиметодов очень легко выполнить, класс Ѕїаїісріѕраїтсһег по-прежнему зависит от 
всех типов, входящих в иерархию. Его преимущества — это быстродействие (если ко- 
личество классов в иерархии не слишком велико) и ненавязчивость (попіпігиѕіхспезѕѕ), 
которая выражается в том, что для использования класса Ѕїатісрі ѕрассһег не нужно 
модифицировать нерархию ТИПОВ. 


11.5. СимметричносіЕ грубого подхода | 


Штриховка пересечения двух фигур может зависеть от того, как именно пересека- 
ются фигуры: прямоугольник накрывает эллипс или наоборот. Иногда это не имеет 
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значения, и штриховка в обоих случаях должна оставаться одинаковой. В этом случае 
нужен симметричный мультиметод (зугатеїгіс пийите!фоа), который не зависит от 
порядка следования его аргументов. 

Симметрия применяется, только если типы обоих параметров идентичны (в нашем 
случае класс Ваѕеіһѕ совпадает с классом Ва5евН5, а +Изтуре$ совпадает с классом 
АһѕТуреѕ). 

Класс Ѕт№атісріѕраїсһег, реализованный в рамках грубого подхода, является 
асимметричным. Это значит, что он не поддерживает симметричные мультиметоды. 
Допустим, например, что мы определяем следующие классы. 


с1аѕ5 нассНіпдЕхеситог 


рибб'іс: 
уо14 Е1ге(вестапд1е&, вестапд1е&) 
уо14 г1ге(вестапд1е&, Е11ірѕе&) 


// обработчик ошибок 
уоїд ОПЕГГОГ($Наре&, $Наре&); 


Туредеї ѕтатісріѕратсһег 
« 
нассіб іпдЕехеситог, 
Варе, . 
ТУРЕІГІ5Т. З(ВестапдТе, Е111рѕе, Ро1у) 


> 
натсһіпоріѕратсћһег; 


Класс Наїсһіпдоіѕратсһег не срабатывает, если ему передать в качестве левого параметра 
класс Е111рзе, а в качестве правого параметра — класс Кестапд1е. Даже несмотря на то, 
что с точки зрения класса нассніпдЕхеситог не имеет никакого значения, какой из этих 
параметров является левым, а какой — правым, класс наєсһіпдріѕратсһег настаивает, 
чтобы объекты передавались в определенном порядке. 

Поменяв аргументы местами и применив другую перегрузку в клиентском коде, 
можно исправить этот недостаток. 


с1аѕ5 натсһіпдЕхеситог 


риђБ1ї1с: 
уоїд Еіге(ВестапдТев, Е11ірѕе&) ; 
// обеспечиваем симметрию 
уоїд Ғіге(Е111рѕе& 1Н5, Кестапд1е& гН$) 
{ 


// Переходим к функции Еї ге (Кессапо1е&, Е11ірѕе&), 
// меняя порядок аргументов 
ЕігеСгћѕ, 11$); 


}; 

Эта небольшая функция обеспечивает симметричность мультиметода. 

В идеале класс Ѕїатісоіѕраєсһег должен был бы сам предоставлять эту возмож- 
ность с помощью дополнительного булевского шаблонного параметра. Для этого нуж- 
но, чтобы в некоторых ситуациях класс 5татісОізрасспег менял порядок следования 
аргументов при обратном вызове. В каких именно ситуациях? Проанализируем пре- 
дыдущий пример. Дополняя список шаблонных аргументов их значениями, заданны- 
ми по умолчанию, мы получаем следующую конкретизацию. 
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туредеї ѕтатісріѕратсһћег 

< 
НатсһіпдЕхеситог, 
Ѕһаре, 
ТҰҮРЕШІЅТ_2 (Вестапд1е, Е11ірѕе, Ро1у), // Класс Ттуреѕһѕ 
Ѕһаре, 
ТУРЕЕТЗТ_2 (Кестапд1е, Е11ірѕе, Ро1у), // Класс ТурезАВН5 
уоїд 


» 
Натсһі паріѕрастћег; 


В симметричном диспетчере можно применить следующий алгоритм выбора пар пара- 
метров: объединим первый тип из первого списка типов (класс Туреіһћѕ) с каждым типом 
из второго списка (класс Турез5ЕН5). Это порождает три комбинации: Весїапд1е- 
Кестапд1е, Кестапд1е-Е111рѕе и Кестапб1е-Ро1у. Затем объединим второй тип из спи- 
ска Туреѕіһѕ с типами из списка Туреѕвһѕ. Однако, поскольку первая комбинация 
(кестапд1е-Е11ірѕе) уже была создана на первом этапе, на этот раз алгоритм начинается 
со второго элемента в списке Турез5ЕН5. Теперь порождаются пары Е11ірѕе-ЕЛ1ірѕе и 
Е111рѕе-Ро1у. Те же рассуждения применяются на следующем шаге: объединение класса 
РОТУ из списка ТурезЕ П5 с типами из списка ТуреѕАһѕ начинается с третьего элемента. На 
этом этапе порождается только одна комбинация — РОТу- РОЇ у. 

Следуя этому алгоритму, мы реализуем функции только для полученных комбинаций. 

Зо Наїсћі пдЕхеситог 

риЬ1їс: 

уоїд Е1ге(вестапд1е&, Вестапд1е&) ; 
уоїй Ғіге(кестапо1е&, Е11ірѕеё&); 
уоїй Ғіге(Аестапд1е&, РОТуві); 

моіа Рі геСЕ111рѕе&, Е111рѕеё&) ; 
моїй Еіге(Е11ірѕе&, Ро1у&) ; 

моїз5 Ріге(РОТуб, Ро1уё) ; 

// обработчик ошибок 

№014 ОПЕГГОГ ($Наре&, $Каре&); 

}; 

Класс ѕтаїісоіѕратсһег должен распознавать комбинации, исключенные нами из 
описанного выше алгоритма, а именно: ЕТ1ір5е-КессапдТе, Ро1у-Кестапд1е и РОТу- 
Е11ірѕе. Для этих комбинаций класс Ѕїатіс0іѕраїсһег должен менять аргументы 
местами, а в остальных случаях поступать, как и прежде. 

Какое булевское условие позволяет определять, когда следует менять аргументы 
местами, а когда нет? Описанный выше алгоритм выбирает в списке ТІ2 лишь типы, 
имеющие индексы, равные или превышающие индекс типа в списке ті1. Следователь- 
но, условие формулируется следующим образом. 


Если индекс типа Ц в списке Туреѕћѕ меньше, чем индекс типа Т в списке 
Туреѕіһѕ, аргументы следует поменять местами. 


Допустим, что типом Т является класс Е11ірѕе, а типом Ц — класс Весфапд]е. Тогда 
индекс типа Т в списке Турезі һћѕ равен І, а индекс типа Ц в списке Туреѕтћѕ равен 
0. Следовательно, аргументы типа Е111ірѕе и Вестапа]е перед вызовом функции 
Ехеситог: : Е1ге следует поменять местами. | 

В набор функциональных возможностей списков типов уже входит статический 
алгоритм Іпдехої, возвращающий позицию типа в списке. Таким образом, сформу- 
лировать условие перестановки параметров довольно легко. 
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Во-первых, мы должны добавить новый шаблонный параметр, который позволяет 
определить, является ли диспетчер симметричным. Затем нужно добавить небольшой 
шаблонный класс характеристик Іпуосасіоптгаїтсѕ, который либо переставляет ар- 
гументы, либо оставляет их на месте перед вызовом функции-члена Ехесисог ; Еі ге. 


хетрТаге 
« 
с1аѕ5 Ехеситог, 
Боо] ѕуттетсгіс, 
с1аѕ5 ВазецН5, 
с1аѕ5 Туреѕіһѕ, 
с1аѕ5 Ваѕевһѕ = Ва5ецН5, 
с1аѕѕ ТурезвА$ = Туреѕіһѕ, 
турепате вез] туре = уоіа 
> 
сТа55 Ѕтаїісріѕратсһег 


тетр1ате <Боо] 5марАгд5, с1аѕѕ ѕЅоте.ћѕ, сТа55 ѕотекһѕ> 
$тгисЕ Іпмосасіоптгаї 5 


зхасіс мої рева зраєскивотенизв 11$, Ѕотедһћѕ& гһѕ, 
Ехеситог& ехес) 


ехес.ҒігеС1ћѕ, гН$); 


}; 
тетр1аїе <с1аѕѕ З5отец|П5, сТа55 Ѕотедһѕ> 
Ѕігисі Іпуосаїіоптгаіїѕ<Тгие, 5оте|Пп5, Ѕотевһѕ> 


{ 
з5хасіс уоіа роріѕраїсћ (ѕоте ћѕ& 1һѕ, Ѕотевһѕ& гһ, 
Ехеситог& ехес) 
ехес.ҒігеСгһѕ, 115); // Меняем аргументы местами 
}; 
риБ11іс: 


ѕтаїіс моїй оіѕра+тсһаһѕ СВваѕе.һѕ& 1һѕ, Ваѕедһѕ& гИ$, 
Ехесиїог ехес) 


(неаа* р2 = дупаптіс_саѕт<неаа“> (&гћѕ5)) 


епит { 5марАгд5 = зуттетг1с && 
Іпдехоб«неайд, ТурезвН$>: : геѕи1+ < 
ІпаехоО#<Вваѕеіһѕ, Туреѕһѕ>: : гези1 т }; 

хуредеб Іпуосаїіоптгаїїѕ<ѕмардгдѕ, Ваѕегһѕ, Неа4> 
Са11тгаітїѕ; 

гетигп Са11тгаіїѕ : : роріѕраєсћ(1һћѕ, *р2); 


е1ѕе 
{ 
гетигп Ѕтаїісоіѕратсһег<Ехеситог, Ваѕегһћѕ, 
ми11туре, Ваѕевһѕ, Таї1»::ОізраєсівнНз ( 
1һ5, гИ$, ехес); 
} 
} 
}; 


Поддержка симметрии немного усложняет класс Ѕёа+ісріѕраїсћ, но намного об- 
легчает его использование. 
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11.6. Логарифмический двойной диспетчер 


Для того чтобы избежать глубоких зависимостей между классами, возникающих 
при грубой реализации двойного диспетчера, нужно поискать более динамичный под- 
ход. Вместо генерирования кода во время компиляции необходимо применить дина- 
мические структуры и алгоритмы, обеспечивающие диспетчеризацию вызовов функ- 
ции во время выполнения программы в зависимости от типов ее параметров. 

Решить эту задачу позволяет механизм ЕТТІ (гапите їуре шЮплаНоп), который дает 
возможность не только идентифицировать типы и выполнять их динамическое приведе- 
ние, но и систематизировать их в ходе выполнения программы с помощью функции-члена 
Бебоге из класса $14: :туре_1пРо. Эта функция упорядочивает отношения между всеми 
типами, определенными в программе, позволяя осуществлять их быстрый поиск. 

Реализация такого класса является усовершенствованным решением задачи 31 из 
книги Скотта Мейерса “Моге еЙесйуе С++” (1996а): этап предварительных вычисле- 
ний (сазіїпе ѕќер) автоматизирован, а реализация максимально обобщена. . 

Воспользуемся классом ОгӣегеатуреІп?о, описанным в главе 2. Этот класс пред- 
ставляет собой оболочку, обладающую функциональными возможностями класса 
ѕта::туре_іпҒо. Кроме того, он имеет семантику значений и оператор “меньше”. 
Это позволяет хранить объекты класса ОгдегедтуретпТо в стандартных контейнерах. 
Именно эта особенность представляет для нас интерес. 

Подход, предложенный Мейерсом, прост: для каждой пары объектов класса 
$14: : туре_ЛпРо, подлежащих диспетчеризации, регистрируется указатель на функцию с 
двойным диспетчером. Этот диспетчер хранит информацию в объекте класса $14: :мар. 
Во время выполнения программы, когда двойному диспетчеру в качестве параметров пере- 
даются два неизвестных объекта, он выполняет быстрый поиск типа (затрачивая логариф- 
мическое время) и в случае успеха возвращает соответствующий указатель на функцию. 

Определим структуру обобщенного механизма, основанного на этих принципах. 
Этот механизм представляет собой шаблонный класс с двумя аргументами (левым и 
правым). Назовем его Ва$1с015ратсНег, поскольку мы будем использовать его в ка- 
честве основы для создания более сложных двойных диспетчеров. 

Тетр]ате <с1аѕ5 ВазеИ$, с1а$$ Вазеві5 = ваѕегһѕ, 


хурепате вези]ттуре = уоїа> 
с1аѕ5 Ва$1с015ратспег 


туредеї $14: :ра1 г<Огаегедтуретт®о, Ог4егедтуретто> 
кеутуре; 

туре4е{ Веѕи1ттуре (С*Са11басктуре) (Ваѕеіһћѕ&, Ваѕевһѕ&) ; 

Туреде{ са11Басктуре марреатуре; 

туреде{ $14: :тар<КеутТуре, Марредтуре> мартуре; 

мартуре са11баскмар_; 

рчБ11с: 

$; 

В качестве ключей карты используются объекты класса $14: :раї г, состоящие из двух 
объектов класса Огаегейдтуретпбо. Класс $т4::ра1г поддерживает систематизацию, 
поэтому для него нам не нужен свой собственный функтор. 

Класс Ваѕісоїѕратсһег станет еще более общим, если сделать тип обратного вызова 
шаблонным. Обычно обратный вызов не обязан быть функцией. Он может быть, напри- 
мер, функтором (глава 5). Класс Ваз ісрізрасспег может адаптировать функторы, преоб- 
разовывая определение их внутреннего типа са11расКТуре в шаблонный. параметр. 
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Значительное усовершенствование заключается в следующем: тип $14: : тар изменени 
стал более эффективным. Мэтт Остерн (Май Аизіегп, 2000) выяснил, что стандартные ас- 
социативные контейнеры имеют более узкую область применения, чем принято думать. В 
частности, упорядоченный вектор в сочетании с алгоритмами бинарного поиска 
(например, алгоритмом 514: : Томег_Боцпа) может оказаться намного эффективнее, чем 
ассоциативный контейнер. Это происходит, когда количество обращений к его элементам 
намного превышает количество вставок. Итак, следует внимательно изучить ситуации, в 
которых обычно применяются объекты двойного диспетчера. 

Чаще всего двойной диспетчер представляет собой структуру, в которую информа- 
ция редко записывается, но из которой часто считывается. Обычно программа лишь 
однажды устанавливает обратные вызовы, а затем очень часто использует диспетчер 
Это хорошо согласуется с использованием механизма виртуальных функций, который 
дополняется двойным диспетчером. Решение о том, какие функции являются вирту- 
альными, а какие нет, принимается на этапе компиляции. | 

На первый взгляд упорядоченный вектор нам совершенно не подходит. Операции 
вставки и удаления элементов такого вектора выполняются за линейное время, и двойной 
диспетчер никак не может повлиять на быстродействие этих операций. Зато этот вектор 
позволяет повысить скорость просмотра элемента примерно в два раза и намного снизить 
объем рабочего множества. Эти свойства очень полезны для двойной диспетчеризации. 

Библиотека [оК! предусматривает использование упорядоченных векторов, опреде- 
ляя шаблонный класс Аз5ос\естог, который может заменять собой класс $514: : тар 
(он содержит те же самые функции-члены), реализованный на основе класса 
514::уестог. Класс Аѕѕосуестог отличается от класса 514::мар функциями еғаѕе 
(функции Аѕѕ0осМесїог::егаѕе аннулируют все итераторы внутри объекта). Кроме 
того, функции-члены іпѕегї и егазе усложнены (выполняя операции вставки и уда- 
ления за линейное, а не постоянное время). Поскольку класс АссоЅУестог совместим 
с классом $14::тар, для описания структуры, содержашейся в двойном диспетчере, 
мы будем также использовать термин ассоциативный массив (тар). 

Ниже приводится новое определение класса Ваѕісріѕраїсћег. 


Ттетр1ате 
< 


с1аѕѕ Ваѕегһѕ, 
сТа55 Ваѕекһѕ = Ва5ецН5, 
Турепате Аеѕи1тТуре = хоїа, . 
хурепате Са11Ьасктуре = кеѕи1стуре (*)(вазегН$&, Ваѕедһѕ& 
> 
сТа55 Ваѕісріѕратсһег 


туредеЁ ѕта: : ра] г<турети®о, туретп®о> 
Кеутуре; 
туредеї са11Ьасктуре марреатуре; 
туредеї д550сМестог<Кеутуре, Марредтуре> Мартуре; 
мартуре са11Баскмар_; 
риЬ1іс: 


}; 
Легко определить и регистрирующую функцию. 


тетр1аќе <...> 
сТа55 ваз5ісрізрасспег 


как и раньше ... 
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тетр1ате <с1аѕ5 ѕЅотеіһѕ, ѕотевһѕ> 

уоіа Ада(Са11Басктуре Фип) 

{ 
сопѕї Кеутуре Кеу(туреїа (ѕЅотегһѕ), туреіа(ѕотекһѕ)); 
са11баскмар_ [кеу] = Рип; 

} 

$; 

Классы Ѕотеіһѕ и 5отевН5 представляют собой конкретные типы, для которых 
выполняется диспетчеризация вызова. Как и класс 511::тар, класс Аззос\естог пе- 
регружает оператор [] для доступа к ключу, который соответствует типу, хранящемуся 
в ассоциативном массиве. Оператор [] возвращает ссылку на новый или найденный 
элемент, а функция дай связывает с ним параметр Ғип. 

Рассмотрим пример, в котором используется функция лай. 

туреде{ Вваѕісоіѕратсһег<ѕһаре> ріѕратсһег; 


// Заштриховывает пересечение прямоугольника и многоугольника 
уоіа натсһіпдкестапо1еро1у(ѕһаре& 115, $Наре& гИ$) 
{ 


вестапа1е& гс = дупат1с_сазт<Вестапа1е&> (11$); 
Ро1у& р)! = дупам1 с_сазт<Ро1у&> (гН$); 
... используем ссылки гс и р1 ... 


} 


61 зратснег Ч15р; 
415р.АЧ9а<вестапда]е, РОТу» (натсһкестапд1еро1у) ; 


Функция-член, выполняющая поиск типа и вызов, довольно проста. 


Тетр1ате <...> 
с1аѕ5 Ваѕісріѕраїһсег 


... как и раньше ... 
Кези]ттуре бо(ваѕегһѕ& 1һѕ, Ваѕекһѕ& гһѕ) 
{ 


мартуре: :1тегатог 1 = са11Ьаскмар_. Гіпа( 
кеутуре (турета(1Н$), туреіа(гһѕ)); 
ЇР (1 == са11баскмар_.епа()? 


їхбгом 514::гипсіте еггог("Функция не найдена"); 
гетигп (1-»5есопа) (1ћ5, гИ$); 
Е 


11.6.1. Логарифмический диспетчер и наследование 


Класс Ваз1с01 5ратсНег неправильно работает с механизмом наследования. Если в нем 
зарегистрирована только функция НатсИвестапа]еро1у($Наре& 1һ5, $Паре& гН$), то 
диспетчеризация распространяется лишь на объекты классов вестапд1е и ро1у. Если, на- 
пример, передать функции Ва$1с01 ѕраїсћһег: : бо ссылки на объекты классов коипдедвес- 
тапд1е и РОТУ, то класс Ваѕісоїіѕраїсһег откажется выполнять вызов. 

Поведение класса Ваѕісріѕратсһег не согласуется с правилами наследования, в 
соответствии с которыми производные типы по умолчанию должны рассматриваться 
как базовые. Было бы прекрасно, если бы класс Ваѕ1сріѕратсһег принимал вызовы, 
параметрами которых являются объекты производных классов, поскольку эти вызовы 
вполне однозначны. 
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Для решения этой проблемы нужно не так уж много, однако до сих пор она не ли- 
квидирована окончательно. Таким образом, при регистрации всех пар типов в классе 
Ваз ісрі 5ратсНег следует проявлять осторожность. 


11.6.2. Логарифмический диспетчер и приведение типов 


Класс Ва51с015рассНег полезен, однако не вполне хорош. Зарегистрированная в 
нем функция, обрабатывающая пересечение между объектами классов Вестапд]е и 
РОТу, должна принимать аргументы базового типа Ѕһаре&. Предлагать клиентскому 
коду (реализации класса наєсһАессапд1еРо1у) привести ссылки на объекты класса 
Ѕһаре к правильному типу не совсем удобно и безопасно. 

С другой стороны, ассоциативный массив обратных вызовов не может хранить 
разные функции и типы функторов для каждого элемента, поэтому следует стремить- 
ся к их единообразному представлению. В параграфе 31 книги Мейерса “Моге 
ЕНеснуе С++” (Меуегѕ, 1996а) эта проблема уже обсуждалась. Преобразование 
“указатель на функцию — указатель на функцию” не подходит, поскольку после воз- 
вращения из функции Епрои61е01 ратсНег: :А44 информация о статическом типе 
теряется, и к какому типу следует приводить параметр, неизвестно. (Попробуйте разо- 
брать какой-нибудь код, и вы сразу поймете, в чем дело.) 

Мы решим задачу динамического. приведения типов с помощью простого обрат- 
ного вызова функций (а не функторов). Таким образом, шаблонный аргумент Са11- 
Басктетр1ате является указателем на функцию. 

Решить задачу нам поможет трамилинная функция (ігатроїпе Гипсйоп), также известная 
под названием санк (ШфипК). Трамплинные функции — это маленькие функции, выпол- 
няющие небольшую настройку перед вызовами других функций. Обычно они используют- 
ся разработчиками компиляторов языка С++ для реализации ковариантных типов возвра- 
щаемых значений и настройки указателей при множественном наследовании. 

Мы будем использовать трамплинную функцию, выполняющую соответствующее 
приведение типов, а затем вызывать функцию с подходящей сигнатурой, облегчая та- 
ким образом работу пользователей. Однако существует одна проблема: объект са11- 
БасКМар_ теперь должен хранить два указателя на функции: один предоставляется 
пользователем, а другой является указателем на трамплинную функцию. Это снижает 
быстродействие программы. Вместо одного косвенного вызова через указатель у нас 
есть два. Кроме того, реализация усложняется. 

Для преодоления этого препятствия воспользуемся следующим фактом. Шаблон 
может получать, указатель на функцию в качестве параметра, лишенного типа. (В 
большинстве книг шаблонные параметры, лишенные типа, представляют собой цело- 
численные значения.) Вообще говоря, в качестве параметров, лишенных типа, шабло- 
ну можно Передавать указатели на любые глобальные объекты, в том числе и функ- 
ции. При этом должно выполняться единственное условие: функция, адрес которой 
является шаблонным аргументом, должна иметь внешнюю связь (ех{егпа! НпКаре). 
Статические функции можно легко превратить в функции с внешней связью, удалив 
ключевое слово ѕтаїіс и поместив их в безымянное пространство имен. Например, в 
стандартном пространстве имен языка С++ можно объявить следующую функцию. 


ѕТатіс №014 вип; 


4 Я убежден, что решение этой проблемы существует. Однако, увы, срок работы над книгой 
ограничен контрактом. 
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В безымянном пространстве имен эта функция объявляется иначе. 
патеѕрасе 


уоіа ғип(); 


Используя указатель на функцию в качестве шаблонного параметра, лишенного 
типа, мы отказываемся хранить его в ассоциативном массиве. Этот важный момент 
следует хорошо уяснить. Мы поступаем так потому, что компилятор обладает статиче- 
ской информацией об этом указателе. Следовательно, компилятор может зафиксиро- 
вать адрес функции в трамплинном коде. 

Эту идею можно реализовать в новом классе, использующем класс Ваѕісріѕратћсег в 
качестве внутреннего буфера (Баск епа). Новый класс Епріѕраїсһег предназначен для 
диспетчеризации только функций, а не функторов. Он включает класс Ваѕісріѕраїсћһег в 
свой закрытый разлел и предоставляет соответствующие интерфейсные функции. 

Шаблонная функция Ғпріѕраїсћһег: :Ада имеет три шаблонных параметра. Два из них 
представляют собой левый и правый типы, для которых регистрируется диспетчеризация 
(классы Сопсгетеці5 и СопсгетевН5). Третий шаблонный параметр (саї 1Баск): является 
указателем на функцию. Дополнительная функция Епріѕраїсһег: :Ааа перегружает опре- 
деленную выше шаблонную функцию дай, имеющую только два параметра. 

тетрТаге <с1аѕ5 Ваѕеіһѕ, сТба55 ВазекИи$ = Ваѕеіһѕ, 


Вези] туре = усій» 
с1аѕ5 ЕпОізрасспег 


ваѕеріѕраїсһеғ<Ваѕегһѕ, Ваѕевһѕ, Кези1ттуре> БаскЕпа ; 


рчБ11с: 
тетр1ате<с1аѕ5 Сопсгетеці5, с1аѕ5 СопсгетевН5, 
ВезиїсТуре (*са11ЬасК) (Сопсгетеці5б, Сопсгетевн56)» 
«019 АЧЧО 


Ѕігисї оса] // см. главу 2 
Ѕтаїіс вези]тТуре Тғарто1іпе (Вваѕегһѕ& 16$, Ваѕекһѕ& кһѕ) 


гетигп саїТраск ( 
дфупаті с, саз с«СопсгетецП56» (115), 
Чупам1 с_са$+<СопсгетевН$&> (гі5)); 
А } 
гетигп раскЕпа .Адд«СопсгетецПп5, Сопсгетевћѕ> ( 
&1оса1: :Тгатро1іпе) ; 
}; 


Используя локальную структуру, мы определяем трамплинную функцию непосредственно 
внутри функции Ада. Трамплинная функция осуществляет приведение аргументов к соот- 
ветствующим типам, а затем передает управление функции, на которую ссылается указа- 
тель обратного вызова. Функция ді добавляет трамплинную функцию в объект 
са11баскмар_ с помощью функции АЯ объекта БаскЕп4_ (определенной в классе 
ваѕеріѕратїсћег). 

С точки зрения быстродействия трамплинная функция не создает дополнительных 
проблем. Хотя она выглядит как косвенный вызов, это не так. Как указывалось выще, 
компилятор фиксирует адрес, хранящийся в указателе обратного вызова, в коде функ- 
ции Тгатро1іпе, поэтому второй косвенный вызов не возникает. Более изощренные 
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компиляторы при малейшей возможности делают трамплинную функцию подстав- 
ляемой. 
Использовать новую функцию дай легко. 


Хуредеї Епріѕратсһег<ѕһаре> рїѕратсһег; 


// Возможно в безымянном пространстве имен 
усід натсһкестапд1еро1у(кестапо1е& 115, РОТу& ГИ$). 
{ 


} 


різрасспег 415р; 

415р.даа<Кестапд1е, РОТу, Натсһ> (); 

Благодаря функции-члену Ааа класс Ғпріѕраїсһег легко использовать. Он также 
позволяет при необходимости обращаться к функции Ай, определенной в классе 
Ваѕеріѕратсћһег.5 


11.7. Класс Еп0Оіѕраїісћһег и симметрия 


Благодаря динамизму класса ғпріѕратсһег добавить в него поддержку симметрии 
намного проще, чем в статический класс ѕ№аїісріѕратсћег. 

Для этого достаточно зарегистрировать две трамплинные функции: одну — для вы- 
зова исполняющей функции при обычном порядке следования аргументов, а вто- 
рую — для перестановки параметров перед вызовом. Добавим в функцию дай новый 
шаблонный параметр. 

хетрТасе <с1аѕѕ Ва5еці5, сТа55 Ваз5евН5 = Ваз5еці5, 


хурепате вези]стуре = моїй» 
сТа55 ЕпОізрасспег 


М 
... 


тетр1ате <с1аѕ5 СопсгетегИ$, с1аѕ5 СопсгетевИ$, 
ВКеѕи1 Туре (*са1ТБасК) (Сопсгетеен$&, Сопсгетевкһћѕ&), 
ђоо1 зуттесгісь 

т АЧдО 


5сгисс Госа 
... Трамплинная функция остается прежней ... 
5схасіс уоіа тгатро11іпе(Ваѕевћѕ& гі5, Вваѕесһѕ& 115$) 
{ 
} 


АЧ4<СопсгетеН$, Сопсгетедћѕ> (&г оса] : :Тгатро11 пе) ; 
1Ғ (зуттесгіс) 


гесигп тгатро1іпе(1ћѕ, гН$); 


ддд«Сопсгесевня, Сопсгетеці5» (боса! : : Тгатро1іпев) ; 
) 
}; 


5 Функцию Ғпріѕраїсһег::АЯй нельзя использовать только для регистрации динамически 
загружаемых функций. Для того чтобы это стало возможно, в программу нужно внести неболь- 
шие изменения. 
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Симметричная диспетчеризация в классе Ғпріѕратсһег реализована на уровне функ- 
ций — для каждой зарегистрированной функции принимается отдельное решение. 


11.8. Двойная диспетчеризация функторов 


Трюк с трамплинными функциями хорошо работает с нестатическими функциями. Бе- 
зымянные пространства имен предоставляют ясный способ замены статических функций 
нестатическими, которые невидимы за пределами данной единицы компиляции, 

Однако иногда нужно, чтобы объект обратного вызова (шаблонный параметр 
Са11басКктуре класса Ваѕісріѕраїсћһег) представлял собой нечто большее, чем обыч- 
ный указатель на функцию. Например, можно потребовать, чтобы каждый объект об- 
ратного вызова сохранял определенное состояние, в то время как функции могут со- 
хранять только значения статических переменных. Следовательно, возникает необхо- 
димость регистрировать для двойной диспетчеризации функторы, а не функции. 

Функторы (глава 5) — это классы, которые перегружают оператор вызова функции 
О, имитируя синтаксис вызова простой функции. Кроме того, функторы могут ис- 
пользовать переменные-члены для хранения своего состояния и доступа к нему. К 
сожалению, трюк с трамплинными функциями не применим к функторам именно по- 
тому, что функторы сохраняют свое состояние, а простые функции — нет. (А где 
трамплинные функции могли бы хранить свое состояние?) 

Клиентский код может непосредственно использовать класс Ваѕісріѕраїсћег, 
конкретизированный соответствующим типом функтора. 


з5зєгисс Наеснриуисфог 


моіа орегатог() (5Паре&, 5Паре&) 
{ 


} 
}; 


туредеї вВва5ісбОізрасспег«5наре, Ѕһаре, моїй, натсНЕипстог> 

натсһіпаріѕратсһег; 

Функция наєспЕцпстог::орегасог О не является виртуальной, поскольку классу Ва- 
ѕ1іс0ріѕраїсһег нужен функтор, имеющий семантику значений, а она плохо согласуется с 
динамическим полиморфизмом. Однако функция натсһћғипстог: : орегатог() может пе- 
реадресовать вызов виртуальной функции. 

Гораздо хуже, что клиент теряет возможности автоматизации, предоставленные 
диспетчером, — приведение типов и поддержку симметрии. 

Похоже, что мы сделали шаг назад, но только если вы не читали главу 5 об обобшен- 
ных функторах. В этой главе определен класс Рипстог, способный содержать любые функ- 
торы и указатели на функции, а также объекты самого класса Ғипстог. Можно даже опре- 
делять специализированные объекты класса Рипстог, выводя их из класса Рипсфогттр1. В 
классе Рипсбсог можно определить приведение типов. Поместив эти средства в библиотеку, 
можно легко реализовать симметричную диспетчеризацию. 

Определим класс Ғипстогріѕраїсһег для любых объектов класса Рипстог. Этот дис- 
петчер содержит класс Ваѕісрі ѕратсћһег, хранящий внутри себя объекты класса Ецпстог. 

Тетр1ате <с1аѕ5 Ваз5еці5, сТа55 ВаѕеКһѕ = ВаѕеіҺѕ, 

хурепате Вези]етуре = усій» 
с1аѕ5 Ғипстогріѕраєсһег 


{ 
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хуредеї Ғипстог<Кеѕи1їТуре, 
ТУРЕЕТЗТ_2 (Ваѕеіһѕ&, Ваѕекһѕ&) > 


Рипстогтуре; 
хуредеї ваѕісріѕраёсһег<Ваѕеіһѕ, ВазевН$, Веѕи1їТуре, 
ғипстогТуре> 
васкЕПатуре; 
васкЕпатуре БбаскЕпа_; 
рибііс: 
}; 


Класс Ғипстогріѕрассһег использует конкретизацию класса Ваѕісріѕраїсһег в 
качестве выходного буфера. Класс Ваѕісріѕраїсһег хранит объекты типа Ғипс- 
тогтуре. Они представляют собой объекты класса Еипсфог, получающие два парамет- 
ра (классов Ва5е| 5 и Ваз5евН5) и возврашающие объект класса Кеѕи1+Туре. 

Функция-член Рипстого15ратсвег: :АЧЯ определяет специализированньй класс 
АЧДартег, производный от класса ЕипстогІтрі. Этот класс предназначен для приведе- 
ния типов. Иными словами, он преобразовывает типы аргументов Ваѕегһѕ и Ва5еві5 
в типы Ѕотеіһѕ и Ѕотевһѕ (этот процесс называется адаптацией). 

Тетр1ате «сТаз55 Ваѕеіһѕ, с1аз5 ваѕекһѕ = вазе И$, 


Вези1ттуре = моїй» 
с1аѕѕ ғипстогріѕратсһег 


как и раньше 
тетр1ате «сТа55 Ѕотеіһѕ, с1аѕ5 Ѕотевһѕ, с1аѕ5 Еип> 
моїа АааСсопѕї Рип& Ғцип) ; 


туредеї - 
ғипстогІтр1<Кеѕи1тТуре, ТУРЕЕТЗТ_2 (Вазе!А5&, Ваѕевһѕ&)> 
рипстогтир1туре; 

с1а55 Аарїег : риБ1іс Еипсбогіпрітуре 


кий Гипо; А 
мігтиа! Кеѕи1їТтуре орегатор () (ваѕегһѕ& 1һѕ, Ваѕедһѕ& гН$) 


‚гетиги Фип_( 
дупатіс са5 є «50тец|П58» (1Н$), 
аупатіс__саѕт<Ѕотевћѕ&>(гһѕ)) ; 


уігіца1 ЕипстогІтр1Туре* С1опе() сопѕї 
{ гетигп пем Адартег; } 

руб11с: 
Адаргег(соп5ї Ғип& Рип): Фип_(Рип) {} 


Баскепа_. АЧа<зотегиз, зотевН$> ( 
| Рипссогтуре (Еипссогітрітуре")пем дАдаарсег(Рип)); 

}; 

Класс АЯартег делает то же, что и трамплинная функция. Поскольку функтор 
имеет состояние, класс Айарїег содержит объекты класса Рип — для трамплинной 
функции это было невозможно. Функция-член СТопе, имеющая очевидную семанти- 
ку, нужна для класса Рипстог. 

Функция Ғипсїогріѕраїсһег: : А4Ч имеет широкое применение. Ее можно использо- 
вать для регистрации не только указателей на функции, но и почти любого функтора, даже 
обобщенного. Для этого нужно лишь, чтобы тип Рип в функции Ааа допускал применение 
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оператора () с аргументами типов 5отенН5 и 5отевН$, а тип возвращаемого значения по- 
зволял преобразование в класс Кеѕи1їтуре. В следующем примере показано, как регист- 
рируются два разных функтора для объекта Рипсїогріѕраїсћһег. 


ТурейеҒ Ғипстогоіѕратсһег<ѕһаре> Юріѕраїсһег; 
ѕтгисї НатсһАестапд1еро1у 


уоіа орегатог(кестапд1е& г, Ро1у& р) 


} 

}; 

зтгист натсһҺЕ11ірѕеАесїапд1е 

1 
уоіа орегатог СЕ11ірѕеё г, Кестапд1её& р) 
} 

$}; 


ріѕраїсһег 415р; 
915р.АЯаа<Вестапд1е, Ро1у> (НатсһКестапд1ерРо1у()); 
` аїѕр.Адй<Е11ірѕе, Кестапд1е> (НатсһЕ11ірѕекестапд1е 0); 

Два этих функтора никак не связаны между собой (хотя являются потомками одного | 
и того же базового класса). Они лишь реализуют оператор () для типов, которые они 
должны обрабатывать. | 

Реализация симметрии класса Ғипстїогріѕраїсһег аналогична реализации симметрии 
класса Епбізратспег. Функция Ғипсїог0їѕраїсһег::Ада определяет новый объект Ве- 
мегѕедаартег, который выполняет приведение типов и меняет порядок вызовов. 


11.9. Преобразование аргументов: $4а#с_са$+ 
или дупатіс са5і? 


Ранее для приведения типов всегда применялся безопасный оператор упаміс_саѕї. 
Однако эта безопасность достигалась за счет снижения эффективности программы. 

В момент регистрации мы уже знаем, что наша функция или функтор будут акти- 
вированы для пары конкретных, точно известных типов. Таким образом, при обнару- 
жении элемента, хранящегося в ассоциативном массиве, механизму двойной диспет- 
черизации известны, фактические типы. Таким образом, излишне повторять проверку 
типов с помощью оператора дупатїс_саѕт, если простой оператор ѕїаїіс_саѕї по- 
зволяет достичь тех же результатов за меньшее время. 

Однако существуют две ситуации, в которых оператор ѕїаїіс._саѕї может оказать- 
ся неприемлемым, вынуждая прибегнуть к динамическому приведению типов с по- 
мощью оператора дупатіс_саѕї. Первая ситуация возникает при использовании 
виртуального наследования. Рассмотрим следующую иерархию классов. 


сТа55 5Наре { ... };. 
с1аѕ5 Весїапд1е : уїгтиа1 рибТіс Ѕһаре { ... У; 
с1аѕѕ Коипдейѕһћаре : уігїџа1 риЫ1іс Ѕһаре { ... }; 


сТа55 Воипаедвестапоїе : рибТіс Вестапаїе, 
рибТіс воипаейѕћһаре { | 


На рис. 11.2 показаны отношения между классами, входящими в эту иерархию. 
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Виртуальный Виртуальный 


Весіапціе Воипдесдібнаре 


ВоипіесВесіагдїв 


Рис. 11.2. “Бриллиантовая” иерархия классов, 
использующая виртуальное наследование 


Возможно, это не самая изящная иерархия классов, но ведь мы никогда не знаем, 
что может понадобиться пользователю. Существуют вполне реальные ситуации, в ко- 
торых необходимы именно “бриллиантовые” иерархии классов, несмотря на все их 
недостатки. Следовательно, двойной диспетчер, определенный нами, должен работать 
с такими иерархиями. 

На самом деле диспетчер по-прежнему вполне справляется с заданием. Однако, 
если заменить оператор Чупаті с са5ії оператором 5сасіс са5і, при попытке привес- 
ти тип ѕһаре& к любому из типов Вестапд1е&, Коип4е4$Наре& или Коцпаедкнестап- 
91е& возникнет ошибка компиляции. Это происходит потому, что виртуальное насле- 
дование отличается от простого наследования. Виртуальное наследование предостав- 
ляет средства, позволяющие нескольким производным. классам совместно 
использовать один и тот же объект базового класса. Компилятор не может просто по- 
местить объект производного класса в память, намертво связав его с объектом базо- 
вого класса. 

В некоторых реализациях множественного наследования каждый производный класс 
хранит указатель на свой базовый объект. Во время приведения производного типа к базо- 
вому компилятор использует этот указатель. Однако объект базового класса не хранит 
указатель на объекты производных классов. С прагматичной точки зрения все это значит, 
что после приведения объекта производного типа к виртуальному базовому типу оказыва- 
ется, что механизма, позволяющего вернуться обратно к объекту производного типа, ком- 
пилятор не имеет. Невозможно выполнить оператор ѕїаїіс_саѕї для перехода от объекта 
виртуального базового типа к объекту производного типа. 

Однако оператор ѕтаїіс_саѕї использует более сложные средства для распознава- 
ния отношений между классами и прекрасно работает даже с виртуальными базовыми 
типами. Короче говоря, для иерархий, использующих зиртуатьном наследование, сле- 
дует применять оператор йупаміс_саѕї. 

Вторая ситуация возникает, когда иерархия классов использует простое (лаже не 
виртуальное) множественное наследование. 


С1а$$ Ѕһаре.{ ... 5;  ... б РИ 
сіа55 вестапа]е : рибібіс ѕһаре 0... У; 
с1аѕ5 воипаейѕһаре : рибТіс Ѕһаре { ... У; 
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сТа55 ВойпдедвестапдТе : рибТіс Кестапд1е, 
рибТтіс Коипаедѕһаре { ... 


На рис. 11.2 показаны отношения между классами, входящими в эту иерархию. 


Воцпдедбнаре 


Весіапдів 


ВоипаеаВесќапдіе 


Рис. 11.3. “Бриллиантовая” иерархия классов, 
использующая невиртуальное наследование 


Несмотря на то что форма иерархии осталась прежней, структура объектов значи- 
тельно отличается от предыдущей. Объекты класса Коипіедвестапд1е теперь могут 
быть двумя разными подобъектами типа Ѕһаре. Это значит, что преобразование объ- 
екта типа Коипдӣейвестапд1е в объект типа $Паре становится неоднозначным. Какой 
тип 5паре имеется в виду — тот, который относится к типу воип4дед$Варе, или тот, 
который связан с типом квестапа1е? Аналогично мы не можем выполнить даже стати- 
ческое приведение типа $Наре& к типу Коипдедвестапа1е&, поскольку компилятор не 
знает, какой из подобъектов типа $Наре имеется в виду. 

Что делать? Рассмотрим следующий код. 

коипдедвестапа]1е гоипавест; 

Аессапд1е& гест = гоипдвест; // однозначное неявное 

преобразование 

ЗНаре& ѕһаре1 = гест; 

воипдед$Паре& гоипдѕһаре = гоип@весут; // однозначное неявное 

преобразование 

Ѕһаре& ѕһаре2 = гоцпіѕһаре; 

Ѕотеріѕратїсћһег 4; 

Ѕһаре& ѕотеотһегѕһаре = ...; 

а.со(ѕһаре1, ѕотеотһегѕһаре); | 

а.Со(ѕһаре2, ѕотеОтһеғѕһаре) ; 

Здесь важно то, что диспетчер использует оператор дупатіс._саѕї для преобразования 
типа Ѕһаре& в тип коипіейѕһаре&. Если попытаться зарегистрировать трамплинную 
функцию для такого преобразования, возникнет ошибка компиляции. 

Если диспетчер использует оператор динамического приведения типов, никаких 
проблем вообше не возникает. Оператор дупаті с. саѕ<Аоипаейкестапд1е& приме- 
няется к любым подобъектам базового класса ѕһаре, позволяя получить правильный 
объект. Очевидно, что лучше динамического приведения типов ничего нет. Оператор 
дупатіс са5ї разработан для получения правильных объектов в иерархии классов, 
независимо от сложности их структуры. 
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Итак, оператор 5сасіс са5і нельзя применять для двойной диспетчеризации ие- 
рархии классов, в которую базовый класс входит несколько раз, независимо от того, 
виртуально наследование или нет. 

Может показаться, что оператор дупатіс_саѕ+ следует применять при создании 
любых диспетчеров. Однако существуют два дополнительных момента. 


Очень немногие реальные иерархии классов используют “бриллиантовую” 
форму наследования. Такие иерархии слишком сложны, и проблемы, которые 
они порождают, перевешивают их достоинства. Поэтому разработчики обычно 
избегают применять такие иерархии классов. 


Оператор дупаміс_саѕ® выполняется намного медленнее, чем оператор 
$фае1с_саз+. Его мощь достигается за счет снижения быстродействия. Многие 
клиенты работают с очень простыми иерархиями классов и хотят, чтобы их 
программы работали быстро. Использование оператора 4упат1с_са$® ставит 
клиентов Перед выбором: разработать совершенно новый диспетчер или внести 
изменения в библиотеку. 


В библиотеке Г.оК! реализована стратегия Са5 Її пдРо1 і су. Она представляет собой 
шаблонный класс с двумя параметрами: исходный и результирующий типы. Стратегия 
содержит единственную статическую функцию Саѕї. Ниже приводится определение 
класса БупатісбСаз ії. 


тетр1ате <с1аѕ5 То, с1аѕ5 Егот» 
5сгисі рупамі сСа5 сег 


}; 


9976 тоб СаѕтСегот& обі) 


гетигп дупатіс са5 «Тов» (обі); 


Диспетчеры Епрізраєспег и Ғипсеогріѕраїтсһег используют стратегию Саз5Т і пд- 
Ро11су, следуя принципам, сформулированным в главе 1. Ниже приводится модифи- 
цированный класс Епріѕраїсһег (изменения выделены полужирным шрифтом). 


тетр1ате 


< 


> 


сТаз5 ВазенН5, 

сТа55 Ва5евН5.- Ваѕеіһѕ, 

везиТетуре = моїй, 

Сетр1ате <с1аѕ5, с1аѕ5> с1аѕ5 Саз1пдРо11су = рупамісСаѕ ег 


сТа55 Ғипс?огріѕраїсһег 


сетрТате <с1аѕѕ Ѕотеьћѕ, с1аѕ5 Ѕотекһѕ, с1аѕѕ Рип» 
моіа Ааа(сопѕ— Еип& Тип) 


сТа55 Адартег : риЬ1іс РипсбогтТуре: : Ітр1 
{ 


кий Ғип_; 
уігтиа1 кеѕи1ттуре орегасогО (ваѕеіһѕ& 1һ5,, 
ваѕевћѕ& гі5) 


гехиги Тип, ( 
Са5 сі пДдРО1 ісу«5отеї| 5, Ваѕеіһѕ>: : Са5 Є (ПН5), 
Са5 сіпдРо1 ісухботеві5, Ваѕевһѕ>: :Са5 є (ГИ5); 
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как и раньше ... 


а зотевй$> ( 
ғипстогтуре (пем Адартег(Фип)); 
} 

}; 

Обратите внимание на то, что по умолчанию стратегия конкретизируется классом 
рупамтіссаѕт. 

В заключение попробуем воспользоваться стратегией приведения типов для достиже- 
ния интересных результатов. Рассмотрим иерархию классов, изображенную на рис. 11.4. 
Одна ее часть не использует “бриллиантовое” наследование, поэтому для нее можно смело 
применять оператор ѕтатіс_саѕї. Например, оператор ѕтатіс._саѕї успешно преобразует 
тип Ѕһаре& в тип Тгіапо1её. С другой стороны, оператор ѕїаїіс_саѕї нельзя применять 
для приведения типа $Наре& к типу Вестапа]е& и любому производному от него типу, 
здесь нужно использовать оператор дупатт с_сазт. 


Тйапое ВоипдеЧ$ Варе 


Весіапціев 
Д 


Яоцпаедйесіѓапдіе 


Рис. 11.4. Иерархия классов, содержащая “бриллиантовую ” часть 


Допустим, что мы определяем свою собственную стратегию приведения типов для 
данной иерархии классов. Назовем ее 5ирегСаз5є. По умолчанию в ней можно приме- 
нять оператор дупат'і с. са5 є, специализируя эту стратегию для отдельных ситуаций. 

тетр1ате <с1аѕ5 То, с1аѕ5 Егот» 

5їгист ЅһаресСаѕтег 


1 
зхасіс тоё СаѕтСғгот& обі) 


гетигп дупаті с са5 «Тов» (обі); 
) 
У; 


тетр1ате<> 
с1аѕ5 5һаресаѕтег<тгіапо1е, ѕһаре> 


зхасіс тгіапо1е& Саѕт Сѕћареҝ& обі) 
гетигп ѕТаїіс._саѕ1<тгіапо1её Собі); 


} 
$; 
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Теперь мы во всеоружии — когда можно, используется быстрое приведение типов, 
а в остальных случаях — безопасное. 


11.10. Мультиметоды с постоянным временем 
выполнения 


Статические диспетчеры слишком ограничены, а динамические слишком медлен- 
ны. Что делать, если нам нужен быстрый и масштабируемый диспетчер? 

В этом случае нужно переработать свои классы, открыв их для вмешательства двойного 
диспетчера. Эта возможность открывает новые перспективы. Поддержка приведения типов 
остается без изменения, однако средства для хранения и обнаружения обработчиков при- 
дется изменить (ведь они имеют логарифмическое время выполнения). 

Чтобы разработать более совершенный механизм диспетчеризации, вновь зададим- 
ся вопросом: что такое двойная диспетчеризация? Ее можно интерпретировать как 
поиск функции (или функтора) на плоскости. На одной из осей отложены типы ле- 
вого оператора, а на другой — правого. Найдя пересечение двух типов, мы отышем 
нужную функцию. На рис. 11.5 показана двойная диспетчеризация для двух иерархий 
классов — $Наре и огамоеу1 се. Обработчиками являются функции рисования, кото- 
рые знают, как изобразить объект класса $Наре с помощью объекта Огам/' пдбемі се. 


Окружность 
Эллипс 
Треугольник 


Прямоугольник 


Экран 
Плоттер 
Принтер 
Память 


Рис. 11.5. Диспетчеризация иерархий 5йаре и Огам/ияБеусе 


Нетрудно догадаться, что для достижения постоянного времени поиска точки на плос- 
кости следует использовать индексированный доступ к элементам двумерной матрицы. 

Идея возникает немедленно: каждый класс должен ассоциироваться с уникальным 
целым числом, представляющим собой индекс в матрице диспетчера. Доступ к этому 
числу из любого класса должен осуществляться за постоянное время. Для этого мож- 
но применить виртуальную функцию. При двойной диспетчеризации вызова диспет- 
чер извлекает два индекса из двух объектов, обращается к обработчику, записанному в 
матрице, и активирует его. Это связано со следующими затратами: два виртуальных 
вызова, одна операция индексирования матрицы и вызов функции через указатель на 
нее. На это уходит постоянное время. 
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На первый взгляд идея прекрасна, однако не все ее детали легко реализовать. Напри- 
мер, поддержка индексирования скорее всего окажется неудобной. Для каждого класса 
нужно задать уникальный идентификационный. номер, надеясь, что компилятор сможет 
обнаружить возможные дубликаты. Отсчет этих номеров следует начинать с нуля и не де- 
лать пропусков, в противном случае в матрице возникнут пустые участки. 

Намного лучше поручить индексирование самому диспетчеру. Каждый класс дол- 
жен хранить свою статическую целочисленную переменную. Ее исходное значение 
должно равняться - 1, что означает “не присвоенный номер”. Виртуальная функция 
должна возвращать ссылку на это целочисленное значение, позволяя диспетчеру из- 
менять его в ходе выполнения программы. При добавлении в матрицу нового обра- 
ботчика диспетчер должен проверить его идентификационный номер. Если он равен 
—1, ему следует присвоить следующий доступный индекс матрицы. | 

Ниже приведена основная часть реализации — макрос, который следует поместить 
в каждый класс, входящий в иерархию. 


#АеР1пе ІМРІЕМЕКТ, ІМОЕХАВІ Е, СІ А55 (ЅотеС1а55) 
з5тагіс іпіб Сеїс1аѕѕ51Іпаехѕтатіс(о\ 


С 5 
ЅТаїіс іп іпаех = -1; \ 
гетигп іпаех; \ 
М 
уїгтиа?! їпоб сегСТаз55Іпадех ОМ 
г 


аѕѕегї (туреїа(*һі5) == туреіа(ѕотес1аѕ5)) ;\ 
гетигп Сбеёс1аѕѕІпдіехѕтатіс 0 ; \ 


Этот макрос следует поместить в открытый раздел каждого класса, для которого 
предусматриваєтся множественная диспетчеризация. 6 

Шаблонный класс ВаѕісҒаѕїріѕраїтсһег предоставляет те же функциональные 
возможности, что и прежний класс Ваѕісріѕраїсһег, используя другие механизмы 
хранения и извлечения данных. 


тетр1ате 
< 
с1аѕѕ Ваѕеіһ, 
с1аѕѕ Ваѕедһѕ = Вваѕеіһѕ, 
Турепате вези]1ттуре = хоїа, . 
Турепате са11Ьасктуре = кеѕи1ттуре (*) (ваѕеіһѕ&, Ваѕе&кһѕ&) 
> 
с1аѕѕ Ваѕісғаѕтріѕратсһег 


туредеї 57а: местог<са11басктуре> ком; 
туредеЕ 574: : уестог<Вом> маєгіх; 
маєгіх са11Баскѕ_; 
іпе со] итп$_; 

риБ1іс: 
Ваѕісғаѕтріѕраєсһег() : соЛ1итпѕ__ (0) {} 
тетр1ате «сТа55 Ѕотеі Һѕ, Ѕотевһћѕ> 
уоіа АаЯ(са11Ьасктуре рғип) 
{ 


їпоб іахіһѕ = Ѕотеіһѕ ; : беїс1аѕѕІіпаехѕтсасіс(); 
іҒ (іахіһѕ < 0) 


6 Именно множественная, а не только двойная. Это решение легко ай на случай 
множественной диспетчеризации. 
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са] 1БасКк$_.ризИ_Баск(Вом()); 
здхіб5 = саїТраск5 .5і2е0О - 1; 


е1ѕе 1 (са11баскѕ__. 512е0) <= іахіһѕ) 
са11баскѕ_. геѕігеСіахіћѕ + 1); 


Ком& Ті 5Вом = са11Ббаскѕ__[іахіһѕ]; 

іп іахаһѕ = 5отевП5: : сес1аѕѕ1Іпадехѕтаїіс() ; 
іҒ (іахаһѕ < 0) 

{ 


Ті ЅҢом. геѕі2еС++со1итпѕ__) ; 
1ахаһѕ = ЕһіѕКом. $17е() 


е1ѕе 158 (1И15Ком.$12е() <= 14хвИ$) 
Тһіѕ Ком. геѕіге(ійхЕһѕ + 1); 


Е = рғип; 
} 
}; 
Матрица обратных вызовов реализуется в виде вектора, состоящего из векторов 
типа Марредтуре. Функция ваѕісғаѕтріѕраїтсһег::АЙЯ выполняет следующую по- 
следовательность действий. 


® Извлекает идентификационный номер каждого класса, вызывая функцию бет- 
С1аѕ51пдехѕїаїіс. 


• Выполняет инициализацию и настройку, если один или оба индекса не были 
проинициализированы. Для неинициализированных индексов функция Ада 
расширяет матрицу, добавляя в нее дополнительный элемент. 


+ Вставляєт обратный вызов в соответствующую позицию матрицы. 


Переменная-член со1итпѕ__ подсчитывает количество столбцов, добавленных к 
данному моменту. Строго говоря, эта переменная излишня. Вычисление максималь- 
ной длины строки в матрице приведет к тому же результату. Однако переменная со1- 
итпѕ__ добавлена для удобства. 

Теперь легко реализовать функцию ваѕісҒаѕїріѕраїсћһег: :60. Основное отличие 
от предыдущей реализации заключается в том, что теперь функция бо использует вир- 
туальную функцию сетс1аѕѕ1піех 


Ттетр1ате <...>. 
сТа55 вазісразчуваранснеї 


.. как и раньше ... 
ВезиТетТуре Со(Ваѕеіћѕ& 1һ5, Вазевн$& гһѕ) 
{ 


іпі& іахіһѕ = 105.СсесСТаз5Іпдех О; 

іпї& 1акһ5 = гһѕ .Сбеїс1аѕѕІпіех(): 

ЗР (іахьһѕ < 0 || іахкһѕ < 0 || 
іахіћѕ >= са11Ббаскѕ_.ѕіғе() | | 
іахкһѕ >= са11Бас$_[1ажьй$].512е() || 
са11Баск$_[1ахьй$] [4 ахаћѕ] 


... обработка ошибок ... 
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гетига саїТрасКк5 Гіахін51 Пахвн51.сатТраск (ПН5, гН$); 
} 

}; 

Подвелем итоги. Мы определили диспетчер, использующий матрицу. Он позволяет 
выполнить обратный вызов на постоянное время с помощью доступа к целочислен- 
ному индексу каждого класса. Кроме того, он выполняет автоматическую инициали- 
зацию данных (индексов, соответствующих классам). Пользователи класса Ваѕісғаѕт- 
015ратсНег должны добавить в каждый класс, использующий диспетчер, одну строку 
макроса ТМРЕЕМЕМТ_ТМОЕХАВЕЕ_СЬА$5 (класс). 


11.11. Классы Вазѕісріѕраїсһег и Ва5ісКа5іОізраїспег как 
стратегии 


Класс ВаѕісҒаѕїіріѕратсһег (основанный на матрице) предпочтительнее класса 
ва5ісрізрасспег (основанного на карте) с точки зрения быстродействия. Однако на 
основе класса Ва5ісбізраєсНнег были разработаны прекрасные классы Епріѕраїсһег 
и Рипссогрізрасспег. Можно ли создать два новых класса — ЕпҒаѕїріѕратсһег и 
РИПСфогРаз$ {01 5ратсНег, которые использовали бы класс ВаѕісҒаѕтріѕраїсһег? 

Лучше попытаться адаптировать классы Епбізраєснег и Рипстого1зратсНег так, 
чтобы они могли использовать класс Ваѕісріѕраёсһег или ВаѕісҒаѕїріѕратсһег в 
зависимости от шаблонного параметра. Таким образом, диспетчер следует реализовать 
в виде стратегии для классов Ғп0іѕраїсһћег и Ғџпстогоіѕраїсһег, как это мы делали 
для приведения типов. 

Задача преобразования диспетчера в стратегию облегчается, поскольку классы Ва- 
ѕісріѕратсһег и ваѕісоіѕратсһег имеют одинаковый интерфейс вызова. Таким об- 
разом, их легко менять местами, изменяя шаблонный аргумент. 

Ниже приводится модифицированное объявление класса ЕПО15ратсйпег (класс 
РипссогОізрасспег объявляется аналогично). 

тетр1ате 

< 

с1аѕ5 Ваѕегһѕ, 
с1аѕѕ Ваѕекһѕ = Ваз5еці5, 
Турепате веѕи1ттуре = моїй, 
тетр1ате «сТа55, сТа55» 
сіаз55 Са5сіпдРоїісу = рупатісСаѕтег, 
хетрТасе <с1аѕѕ, с1аѕѕ, с1аѕѕ, с1аѕѕ> 
с1аѕѕ ріѕраїтсһегваскепа = Ваѕісріѕратсһег 

> 

с1аѕ5 ЕпрОізрасспег; // Аналогично классу РипссогОізраєсснег 
Сами классы практически не изменяются. 

Уточним требования, предъявляемые к стратегии ріѕратсһегваскепа. Прежде 
всего, очевидно, что эта стратегия должна быть шаблонным классом с четырьмя па- 
раметрами. Семантика этих параметров такова. 


• Тип левого операнда. 
• Тип правого операнда. 
• Тип значения, возвращаемого обратным вызовом. 


» Тип обратного вызова. 
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В табл. 11.1 класс Васкепатуре представляет собой конкретизацию диспетчера, а 
объект БаскКЕПЧ_ — переменную этого типа. Таблица содержит функции, о которых 
мы не упоминали, — не беспокойтесь. Полное описание диспетчера должно содер- 
жать функции удаления обратных вызовов и “пассивного” просмотра без обращения 
к обратным вызовам. Они реализуются тривиальным образом. Их описание приведено 
в библиотеке ГоК! в файле ми1®ітесћоаѕ.һ. 


Таблица 11.1. Требования, предъявляемые к стратегии ОіѕраїсһегВаскепа 


Выражение Тип возвращаемого Примечания 
значения 

сору, а55ідп, 5мар, Пеѕтгоу Семантика значений 
БаскЕпЯ.Ааа<ѕотеіһћѕ, моіа Добавляет обратный вызов в 
5отевл5» Сса11ЫЬаск) объект БасКЕпа для типов 

Ѕотегһћѕ и 5отевН5 
БасКЕпа. Со (Ваѕегһѕ&, Кеѕи1ттуре Выполняет просмотр и 
ваѕекһѕё) диспетчеризацию для двух 


объектов. Если обработчик не 
найден, генерирует 
исключительную ситуацию 
5:д::гипсуте еггог 


БаскЕпа. кетоме<ѕомегћѕ, Боо1 Удаляет обратный вызов для 

зотекН$> () типов зотегН$ и зотевН$. Если 
обратный вызов существовал, 
возвращает значение Сгие 


БасКЕпЧ .НапаТегЕх1 51$ Боо] Если обратный: вызов для типов 
«5отеці5, 5отевНн5» 0 Зопеці5 и 5отевН5 


зарегистрирован, возвращаєт 
значение тгие. Новый обратный 
вызов не добавляется 


11.12. Перспективы 


Мы стоим на пороге новых обобщений. Результаты, полученные при разработке 
двойного диспетчера, можно применить для реализации действительно обобщенной 
множественной диспетчеризации. 

На самом деле это довольно просто. Мы определили три типа диспетчеров. 


• Статический диспетчер, управляемый двумя списками типов. 


• Диспетчер, управляемый ассоциативным массивом, содержащим пары объектов 
типа 514: : суре_1пРо7 в качестве ключей. 


» Диспетчер, управляемый матрицей, индексированной уникальными идентифи- 
кационными номерами классов. 


Эти диспетчеры можно легко обобщить. Статический диспетчер, управляемый 
двумя списками типов, можно преобразовать в диспетчер, управляемый одним спи- 


7 Эти объекты скрыты под оболочкой класса Огае гедТуреїпіо, облегчающего сравнение 
и копирование. 
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ском типов, элементами которого в свою очередь являются списки типов. Это вполне 
реально, поскольку списки типов также являются типами. Ниже приведен оператор 
Хуредеї, определяющий список типов, состоящий из трех списков типов, который 
можно применить для тройной диспетчеризации. Интересно, что возникающий в ре- 


зультате список действительно легко прочесть. 
туредеї ТУРЕЕТ$ЗТ_3 
( 


ТУРЕІІ5Т 3(5Наре, ВессапдТе, Е111ірѕе), 
ТУРЕШІ5Т З(5сгееп, Ргіпсег, Р1оїтег), 
ТУРЕЕТЗ$Т_3(Е1]е, 5осКее, метогу) 


150111515; 


Диспетчер, управляемый ассоциативным массивом, можно преобразовать в диспетчер, 
управляемый вектором объектов типа 514; :туре_Тп®о (в отличие от типа $14: : ра1 г). 
Размер этого вектора равен количеству объектов, вовлеченных в множественную диспетче- 


ризацию. Объявление этого класса может выглядеть следующим образом. 
тетр1ате 
< 
сТаз5 11510#туреѕ, 
Турепате Кеѕи1єтуре, 
хурепате Са11ЬасКтуре 
> 
с1аѕ5 Сбепега1ваѕісріѕратсћег; 


Шаблонный параметр 11510#туреѕ представляет собой список типов, содержащий базо- 
вые типы, вовлеченные в множественную диспетчеризацию. Например, при штриховке 
пересечения двух фигур можно было бы применить список түрЕ\І5Т_2 (Ѕһћаре, Ѕһаре). 

Диспетчер, управляемый матрицей, можно обобщить с помошью многомерного 
массива, который можно построить на основе рекурсивного шаблонного класса. Су- 
ществующая схема присвоения идентификационных номеров остается неизменной. 
Следует отметить, что иерархию классов, используемую для двойной диспетчериза- 
ции, можно без изменения применять и лля множественной диспетчеризации. 

Все эти возможные расширения требуют большого объема работы. Особенно труд- 
ная проблема, связанная с множественной диспетчеризацией, заключается в том, что 
в языке С++ нет универсального способа представления функций, имеющих пере- 
менное количество аргументов. 

В настоящий момент библиотека Ї.оКі реализует лишь двойную диспетчеризацию. 
Ее обобщения читатели могут попробовать осуществить самостоятельно: 


11.13. Резюме 


Мультиметоды — это обобщенные виртуальные функции. Система поддержки вы- 
полнения программ на языке С++ реализует диспетчеризацию виртуальных функций 
по одному классу, а мультиметоды осуществляют множественную диспетчеризацию в 
зависимости от нескольких классов одновременно. Это позволяет реализовать вирту- 
альные функции для наборов типов, а не для отдельного типа. 

Мультиметоды лучше всего реализовывать как свойство языка. В языке С++ таких 
средств нет, но есть несколько способов, позволяющих использовать мультиметоды в 
виде библиотек. 

Мультиметоды нужны в приложениях, выполняющих те или иные алгоритмы в за- 
висимости от типов одного или нескольких объектов. Обычно они применяются для 
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обработки столкновений или пересечений полиморфных объектов, а также отображе- 
ния объектов разными устройствами. 

В этой главе мы ограничились двойной диспетчеризацией. Объект, выполняющий 
вызов соответствующей функции, называется двойным диспетчером. Существует не- 
сколько типов дипспетчеров. 


• Статический диспетчер. Он полагается на информацию о статических типах 
(предоставленную в виде списка типов) и выполняет линейный развернутый 
поиск соответствующего типа. Как только требуемый тип найден, диспетчер 
вызывает перегруженную функцию-член для обработки объекта. 


• Диспетчер, управляемый ассоциативным массивом. Он использует ассоциативный 
массив, ключами которого являются объекты класса 514: : уре_1пФо. В этом 
массиве хранятся обратные вызовы (либо указатели на функции, либо функто- 
ры). Алгоритм распознавания типа выполняет бинарный поиск. 


• Диспетчер, управляемый матрицей. Это самый быстрый диспетчер, однако для 
его применения нужно модифицировать классы (добавить макрос в каждый 
класс, к которому применяется диспетчеризация). Для такой диспетчеризации 
нужно выполнить два виртуальных вызова, набор числовых проверок и опера- 
цию доступа к элементу матрицы. 


На основе указанных выше диспетчеров можно реализовать следующиє функцио- 
нальные возможности. 


• Автоматизированное преобразование типов. (Не путайте с автоматическим 
преобразованием типов.) Для вызова диспетчеров необходимо выполнить 
приведение базовых типов к производным. Для этого предназначены трам- 
плинные функции. 


е Симметрия. Некоторые варианты использования двойной диспетчеризации 
являются симметричными по своей природе. Они применяются к одинако- 
вым типам, и порядок следования параметров для них не важен. Например, 
обработчику столкновений все равно -— ракета столкнулась с космическим 
кораблем или наоборот — его реакция будет одинаковой. Реализация сим- 
метрии в библиотеке позволяет уменьшить размер клиентского кода и из- 
бежать многих ошибок. 


Статический диспетчер, основанный на грубом подходе, непосредственно поддер- 
живает эти возможности, поскольку ему доступна обширная информация о типах. Ос- 
тальные диспетчеры используют разные методы и добавляют новые уровни иерархии 
для реализации автоматизированного преобразования типов и подлержки симметрии. 
Двойные диспетчеры функций отличаются от лвойных диспетчеров функторов. Они 
более эффективны. 

В табл. 11.2 приведены результаты сравнения разных диспетчеров, определенных в 
этой главе. Очевидно, что ни один из них не идеален. Выбор оптимального диспетче- 
ра зависит от конкретной ситуации. 
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Таблица 11.2. Сравнение разных реализаций двойной диспетчеризации 


Статическая Логарифмическая Диспетчеризация 
диспетчеризация диспетчеризация с постоянным 
(класс (класс временем (класс 
ЗіайсЮієраїспег) Ваѕісріѕраќсћег) ВаѕісЕаѕ{Юіѕраќсһег) 
Скорость для Самая высокая Средняя Хорошая 
нескольких классов | 
Скорость для Низкая Хорошая Самая высокая 
многих классов 
Зависимость между Сильная Слабая Слабая 
классами 
Переключение между Нет Нет В каждый класс 
существующими добавляется макрос 
методами І 
Безопасность Самая высокая Хорошая Хорошая 
КОМПИЛЯЦИИ 
Безопасность Самая высокая Хорошая Хорошая 


выполнения 


11.14. Краткий обзор двойных диспетчеров 


314 


В библиотеке Го определены три вида двойных диспетчеров: 
Ѕтатісріѕратсћһег, Ваѕісріѕратсћһег и ВаѕісРаѕїріѕратсћһег. 


классы 


Объявление класса Ѕїатісріѕратсһег 


тетр1ате 
< 
с1аѕѕ Ехеситог, 
с1аѕ5 Ваѕегһѕ, 
с1аѕ5 туреѕіһѕ, 
с1аѕ5 Ваѕекһѕ = Ваѕегһѕ, 
с1аѕ5 Туреѕкһѕ = Туреѕіһѕ, 
Турепате Аеѕи1ттуре = моїа 
> 
с1аѕѕ Ѕтатісріѕратсћһег; 


Класс Ваѕегћѕ — это базовый тип левого операнда. 


Класс Туреѕ_һћѕ представляет собой список типов, содержащий набор конкретных 
типов, вовлеченных в двойную диспетчеризацию в зависимости от левого операнда. 
Класс ва5еві5 — это базовый тип правого операнда. 

Класс ТуреѕАһѕ представляет собой список типов, содержащий набор конкрет- 
ных типов, вовлеченных в двойную диспетчеризацию в зависимости от правого 
операнда. 

Класс Ехеситог содержит функции, вызываемые после распознавания типов. 


Он должен содержать перегруженную функцию-член Бі ге для каждой комби- 
нации типов, указанных в списках типов Туреѕіһѕ и ТурезвИ$. 


Класс Кезиїстуре определяет тип значений, возвращаемых перегруженными 
функциями Ехеситог::Еїге. Эти значения передаются дальше в качестве ре- 
зультата работы функции Ѕїатісріѕраїсћһег: : бо. 
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» Класс  Ехесибог должен содержать перегруженную  функцию-член  ОпЕГ- 
гог(Ваѕеіћѕ&, Вазекн$&) для обработки ошибок. Функция Ехеситог: : ОпЕггог 
вызывается классом $$а{1с015рахсНег при обнаружении неизвестного типа. 


+ Допустим, что классы кестапд1е и Е11ірѕе являются потомками класса $Паре, 
а классы Ргіптег и 5сгееп — потомки класса бисрисремі се. 
5Сгисс Раїпсег 


роо1 ЕігеСАестапо1е&, РГіптегб); 
Боо] Еіге(Е11ірѕе&, Ргіпіег&) ; 

Боо] Еіге(ВестапдТеб, Ѕсгеепё&) ; 

Ьоо1 Еіге(Е111ірѕе&, Ѕсгееп&) ; 

Боо1 ОПЕггог($Наре&, Оитриїремісеё&) ; 


}; 
Хуредеї ѕїатсісоіѕратсһег 
< 

Раіптег, 

Ѕһаре, 


ТҮРЕШІЅТ_2 (Вестапд]е, Е111рѕе), 
Оитритреуісе, 
ТУРЕЕТУТ_2 (Ргіптег&, 5сгееп), 
Боо] 

> 

О15ратсНег; 


• Класс зтат1со15ратсИег реализует функцию-член бо, получающую параметры, 
имеющие типы Ваѕеіһѕ&, Ваѕевһѕ& и Ехеситог& соответственно. Вот пример 
ее использования (в контексте предыдущих определений). 

ріѕраїсһег 415р; 

Ѕ5һаре* рѕһ = ...; 

Оитритреуісе* рбем = ...; 

Боо] геѕи1т = 15р. со(*рѕһ, *роем); 

• Классы Ваѕісріѕраїтсһег и ВаѕісҒаѕїріѕратсһег реализуют динамические 
диспетчеры, позволяющие пользователям добавлять обрабатывающие функции 
в ходе выполнения программы. 


• Класс Ваѕісріѕратсһег находит обработчик за логарифмическое время. Класс 
Ваѕісғаѕтріѕраїсһег находит обработчик за постоянное время, однако для 
этого пользователь должен изменить определения всех классов, вовлеченных в 
диспетчеризацию. 


• Оба класса имеют одинаковый интерфейс. 


тетр1ате 
< 
сТа55 Ваѕеіһѕ, 
с1аѕѕ Ваѕевһѕ = Ваѕегһ, 
турепате Кеѕи1ттуре = моїд, 
турепате Са11Ьасктуре = ВезиїстТуре (7) 
(Вваѕеіһѕ&, ВаѕеАһѕ&) 
> 
с1аѕѕ Ваѕісріѕраїсһег; 


‚ | Здесь класс Са11ьасктуре является типом объекта, выполняющего диспетчери- 
зацию. Классы Ваѕісріѕраїсһег и ВаѕісҒаѕіріѕраёсһег хранят и вызывают 
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объекты этого типа. Все остальные параметры имеют тот же смысл, что и в 
классе 5сасісрізрассПег. 


Функции, реализуемые классами Ваѕісріѕратсһег и ВаѕісҒаѕтріѕратїсћһег, 
перечислены в табл. 11.1. 


Кроме указанных трех основных диспетчеров, в библиотеке [окі определены 
еще два диспетчера: классы Епбізраєсснег и Ғипстогріѕратсһег. Они исполь- 
зуют классы Ваз5 ісСОі зрассНнег и ВаѕісҒаѕріѕратсћһег в качестве стратегий. 


Классы Епріѕратсһег и Ғипссогріѕратссһег имеют одинаковые объявления. 


тетр1ате 
< 
сТа55 Ваѕеіһ5ѕ, 
с1аѕѕ Ваѕекһѕ = Ваѕеіһ, 
везиТбстуре = моїй, 
сетрТасе <с1аѕѕ То, с1аѕѕ Егот> 
с1аѕ55 Саѕтіпдро1ісу = рупатісСаѕт 
тетр1ате <с1аѕѕ, с1аѕѕ, с1аѕѕ, с1аѕѕ> 
с1аз$ ріѕратсһегваскепа = ваѕісріѕраїсһег 
> 
с1аѕ5 Еп0іѕраїсһег; 


Здесь классы Ваѕеіһѕ и Ва5евНн5 — это базовые классы двух иерархий, вовле- 
ченных в двойную диспетчеризацию. Класс кеѕи1ттуре задает тип значения, 
возвращаемого обратными вызовами и диспетчером. Класс СаѕііпдрРо1ісу — 
это шаблонный класс с двумя параметрами. Он должен реализовывать функ- 
цию-член Саѕї, принимающую ссылку на объект класса Егот и возвращающую 
ссылку на объект класса То. Основные реализации классов Бупат1 сСазтег и 
5хасісСаз5 сег используют операторы даупатіс са5ї и ѕтаїіѕ__саѕї соответст- 
венно. Шаблонный класс рі ѕратсһегВаскепа реализует тот же интерфейс, что 
и классы Ваѕісріѕраїсћһег и ВаѕісҒаѕтріѕратїсћһег, описанный в табл. 11.1. 


И класс Епріѕратсһег, и класс ЕцпстогОї зратснег определяют функцию-член 
Ааа или основные типы обработчиков. Для класса Епріѕратсһег основным ти- 
пом обработчика является класс вези1ттуре(*) (вазе! И5&, Ваѕекһѕ&). Для 
класса РипстогО1 зрафсвег основным типом обработчика является класс Ғипс- 
тог<вези] Туре, ТУРЕЕТЗТ_2 (Вваѕеіһѕ&, Ваѕевһѕ&)>. Описание класса Ғипс- 
тог дано в главе 5. 


Кроме того, класс ЕПО15$ратсНег определяет шаблонную функцию, предназна- 
ченную для регистрации обратных вызовов. 
моїд даа<ѕотеіһѕ, ѕотекһѕ, 

Ве5и1ттуре С*са11ЬасК) Сѕотегһѕ&, Ѕотевһѕ&) , 

ђоо1 ѕумметгіс> () ; 
Если обработчик регистрируется функцией-членом Аа, описанной выше, 
пользователь получает преимущества автоматизированного приведения типов и 
симметрии. 


В классе Ғипстогріѕратсһег определяется шаблонная функция-член дай. 


тетр1ате <с1а55 зотегИ$, с1а55 Ѕотекһѕ, с1а$$ Е> 
уоіа Ааа (сопѕї ЕФ Ғип) ; 


Класс Е может быть одним из типов, получаемых объектом класса Ғипсїог 
(глава 5), включая другую конкретизацию класса Ғипсїог. Объект класса Е 
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должен допускать выполнение оператора вызова функции с аргументами, 
имеющими типы Ваѕе һѕ& и Ва5евН56, и возвращать значение, тип которого 
может быть преобразован в тип Вези1 «Туре. 


Если обработчик не найден, все механизмы диспетчеризации генерируют ис- 
ключительную ситуацию, имеющую тип $19: : гипт1те_еггог. 
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Приложение 


МНОГОПОТОЧНАЯ БИБЛИОТЕКА 
В СТИЛЕ МИНИМАЛИЗМА 


В многопоточной программе одновременно существует несколько точек выполне- 
ния. Это значит, что в такой программе несколько функций могут выполняться па- 
раллельно. В многопроцессорных компьютерах разные потоки выполняются одновре- 
менно в буквальном смысле этого слова. В то же время многопоточные операционные 
системы в однопроцессорных машинах применяют режим разделения времени (ите 
51ісіпв) — они разделяют каждый поток на короткие интервалы времени, откладывают 
его и предоставляют процессорное время другому потоку. Это создает у пользователя 
иллюзию параллельного выполнения нескольких функций. Например, текстовый 
процессор может проверять грамматику, пока пользователь вводит текст. 

Пользователи не желают любоваться песочными часами, пока выполняются другие 
потоки, поэтому программисты должны разрабатывать многопоточные программы. К 
сожалению, обычно их очень трудно создавать и еще труднее отлаживать. Более того, 
многопоточность пронизывает все приложение. Создать внешнюю библиотеку, кото- 
рая надежно работала бы в многопоточном режиме, невозможно, даже если сама биб- 
лиотека не использует потоки. 

Отсюда‘ следует, что нельзя игнорировать вопросы, связанные с многопоточно- 
стью. (Разумеется, на самом деле можно обойтись и без этого, однако в таком случае 
они станут совершенно бесполезными в многопоточной среде.) Поскольку современ- 
ные приложения все интенсивнее используют многопоточное выполнение, было бы 
глупо игнорировать многопоточность просто из-за лени. 

В приложении описываются средства и приемы, позволяющие разрабатывать машин- 
но-независимые многопоточные объектно-ориентированные приложения на языке С++. 
Его нельзя рассматривать как полноценное введение в многопоточное программирование. 
Попытка рассмотреть все вопросы, связанные с разработкой многопоточной библиотеки, 
была бы бесполезной и обреченной на провал. Таким образом, мы сосредоточимся лишь 
на минимальных абстракциях, позволяющих создавать многопоточные компоненты. 

Функциональные средства для поддержки многопоточного режима, реализованные в 
библиотеке [Г оК, скудны по сравнению с огромным количеством средств, предоставляемых 
современными операционными системами, поскольку они ориентированы только на 
обеспечение безопасности работы потоков. С другой стороны, концепции синхронизации, 
определенные в этом приложении, находятся на более высоком уровне, чем традиционные 
мьютексы (тшехез) и семафоры (зетарвоге$) и могут оказаться полезными при разработке 
любого объектно-ориентированного многопоточного приложения. 


П.1. Критика многопоточности 


Преимущества многопоточного режима в многопроцессорных машинах очевидны. Но 
если компьютер имеет один процессор, многопоточность выглядит довольно глупо. Зачем 
замедлять работу процессора, заставляя его работать в режиме разделения времени? Оче- 
видно, что выигрыша во времени это не дает. Чудес не бывает — у нас по-прежнему лишь 
один процессор, поэтому в целом многопоточный режим даже немного снизит эффектив- 
ность из-за дополнительных операций обмена данными и регистрации. 

Причина, по которой многопоточный режим все же применяют в однопроцессор- 
ных машинах, заключается в эффективном использовании ресурсов. Типичный совре-. 
менный компьютер имеет намного больше ресурсов, чем один процессор. Он снабжен 
дисководами, модемами, сетевыми картами и принтерами. Поскольку все они с физи- 
ческой точки зрения независимы друг от друга, их ресурсы можно использовать одно- 
временно. Например, не существует причин, запрещающих процессору производить 
вычисления, пока выполняется запись информации на диск или вывод результатов на 
принтер. Однако это оказывается действительно невозможным, если приложение и 
операционная система жестко связаны только с однопоточной моделью выполнения 
программы. Вряд вы обрадовались, если бы ваше приложение не позволило вам ни- 
чего делать, пока не завершится загрузка данных из Интернет. 

Кроме того, даже процессор в какие-то моменты времени оказывается в простое. При 
редактировании трехмерных изображений короткие интервалы времени между движения- 
ми мыши и щелчками кажутся процессору вечностью. Было бы хорошо, если бы програм- 
ма для рисования изображений могла использовать эти моменты простоя для выполнения 
полезной работы, например, отслеживания луча или вычисления скрытых линий. 

Основной альтернативой многопоточности является | асинхронноє выполнение 
(аѕіпсһгопоиѕ ехесийоп). Режим асинхронного выполнения программы основан на модели 
обратных вызовов (саПбасК по4е!): при выполнении операции производится регистрация 
функции, которую следует вызвать после ее завершения. Основным недостатком асин- 
хронного выполнения программы по сравнению с многопоточным режимом является из- 
быток состояний программы. Используя асинхронную модель, нельзя проследить выпол- 
нение алгоритма шаг за шагом — можно лишь хранить состояние и позволять обратным 
вызовам его изменять. Поддержка такого состояния весьма проблематична и легко реали- 
зуется лишь для простейших операций. 

Истинная многопоточная модель лишена таких недостатков. Каждый поток имеет 
неявное состояние, определяемое его точкой выполнения (оператором, который вы- 
полняется потоком в данный момент). Работу потока легко проследить, как если бы 
он был простой функцией. В асинхронной модели программист должен сам управлять 
точкой выполнения. (Основной вопрос асинхронного программирования: “Где я?”.) В 
заключение отметим, что многопоточные программы могут реализовывать синхрон- 
ную модель выполнения, что уже хорошо. 

С другой стороны, потоки порождают большие проблемы, поскольку они совмест- 
но используют ресурсы, например, данные, записанные в памяти. В любой момент 
потоки могут прерываться другими потоками (да, именно в любой момент, даже по- 
среди присваивания), поэтому операции, которые мы привыкли считать атомарными, 
таковыми больше не являются. Неорганизованный лоступ потоков к данным также 
может стать причиной потери информации. 

В однопоточном программировании безопасность данных при входе и выходе 
функции обычно гарантируется. Например, оператор присваивания (орегатог=) из 
класса 5%г1пд считает объект класса $%г1пд корректным только перед началом и по- 
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сле завершения операции. В многопоточном программировании необходимо обеспе- 
чивать корректность объекта класса 51 гіпд даже во время выполнения оператора при- 
сваивания, поскольку другой поток может прервать выполнение этого оператора и 
применить к этому объекту. другую операцию. В то время как однопоточное програм- 
мирование приучает программистов рассматривать функции как атомарные операции, 
в многопоточном программировании необходимо самому указывать, какие операции 
являются атомарными. Итак, многопоточные программы порождают большие про- 
блемы при совместном использовании данных; что следует считать их недостатком. 

Большинство способов многопоточного программирования основное внимание уделя- 
ют оббектам синхронизации (зупсргопітацоп обес), позволяющим обеспечивать последова- 
тельный доступ к совместно используемым ресурсам. При выполнении атомарной опера- 
ции объект синхронизации захватывается. Если другие потоки пытаются захватить тот же 
объект синхронизации, они фиксируются. Затем данные изменяются, и объект синхрони- 
зации освобождается. В этот момент его может захватить другой поток, получив доступ к 
данным. Таким образом, потоки всегда работают с корректными данными. 

В следующем разделе будут описаны разные способы захвата. Их перечень не ис- 
черпывается объектами синхронизации, хотя эти объекты позволяют решить боль- 
шинство задач многопоточного программирования. 


П.2. Подход, реализованный в библиотеке Гокі 

Для решения проблем, связанных с многопоточностью, в библиотеке ГоК! опреде- 
лена стратегия тһгеадіпомоде1. Эта стратегия представляет собой шаблонный класс с 
одним аргументом. Такой аргумент является типом языка С++, для которого реали- 
зуются функциональные возможности многопоточного программирования. 


Тетр1ате <турепате т> 
с1аѕ5 Ѕотетћгеадіпдмоде1 


В. следующих разделах мы последовательно раскроем содержание стратегии 
ТИгеа91помо4Че1. В библиотеке ТоК! определена однопоточная модель, которая в 
большинстве случаев используется по умолчанию. 


П.З. Атомарные операции с целочисленными типами 
Допустим, что переменная х имеет тип 1пе. Рассмотрим оператор 
++х; 
Может показаться странным, что мы уделяем время анализу простого оператора инкре- 
ментации, однако именно в таких ситуациях проявляются особенности многопоточного 
программирования — для решения простых проблем нужно приложить много усилий. 
Чтобы увеличить значение переменной х на единицу, процессор выполняет три 
операции. 
1. Извлекает переменную из памяти. 


2. Увеличивает значение переменной в арифметико-логическом устройстве (АЛУ) 
процессора. Это единственное место, где выполняются операции — в памяти 
данных они лишь хранятся. 


3. Переменная записывается обратно в память. 
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Поскольку первая операция считывает, вторая — модифицируєт, а третья — записы- 
вает данные, они образуют тройку, известную по названием операция чтения- 
модификации-записи (геад-тодіїу-мтіте орегайоп — ВМУУ). 

Предположим теперь, что оператор инкрементации выполняется в компьютере с 
многопроцессорной архитектурой. Для того чтобы достичь максимального эффекта во 
время модификации данных в процессе выполнения операции чтения-модификации- 
записи, процессор освобождает шину запоминающего устройства. Таким образом, 
второй процессор получает доступ к памяти, пока первый выполняет операцию ин- 
крементации. Это позволяет эффективнее использовать ресурсы. 

К сожалению, другой процессор может применить операцию чтения-модификации- 
записи к той же переменной. Например, допустим, что существуют два оператора инкре- 
ментации переменной х, которая в начальный момент времени имеет значение 0, и эти 
операторы выполняются двумя процессорами РІ и Р2 в такой последовательности. 


1. Процессор РІ захватывает шину запоминающего устройства и извлекает пере- 
менную х. 


2. Процессор РІ освобождает шину запоминающего устройства. 


`3. Процессор Р2 захватывает шину запоминающего устройства и извлекает пере- 
менную х (значение которой по-прежнему равно 0). В то же время процессор РІ 
увеличивает значение переменной х на единицу в своем арифметико- 
логическом устройстве. Результат равен 1. 


4. Процессор Р2 освобождает шину запоминающего устройства. 


5. Процессор Рі захватывает шину запоминающего устройства и записывает зна- 
чение 1 в переменную х. Одновременно процессор Р2 увеличивает значение пе- 
ременной х на единицу в своем арифметико-логическом устройстве. Поскольку 
процессор Р2 извлек значение 0, результат снова равен |. 


6. Процессор Р2 освобождает шину запоминающего устройства. 


7. Процессор Р2 захватывает шину запоминающего устройства и записывает зна- 
чение 1 в переменную х. 


8. Процессор Р2 освобождает шину запоминающего устройства. 


В итоге, хотя к переменной х были применены две операции инкрементации, ее зна- 
чение станет равным 1, а не 2. Это неверный результат, причем ни один процессор 
(поток) не сможет распознать, что операция инкрементации была выполнена неверно. 
В многопоточной среде ничто не является атомарным — даже простая операция ин- 
крементации целого числа. 

Есть множество способов сделать операцию инкрементации атомарной. Наиболее 
эффективный из них — использовать возможности процессора. Некоторые процессо- 
ры предоставляют возможности блокировки шины запоминающего устройства — опе- 
рация чтения-модификации-записи выполняется как и раньше, однако во время ее 
выполнения шина запоминающего устройства остается заблокированной. Таким обра- 
зом, процессор Р2 извлекает переменную х из памяти только после того, как процес- 
сор Р1 выполнит свою операцию инкрементации. 

Эта низкоуровневая функциональная возможность реализуется операционной сис- 
темой с помощью функций на языке С, использующих атомарные операции инкре- 
ментации и декрементации. 
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Обычно операционные системы определяют атомарные операции для целочисленных 
типов, размер которых совпадает с шириной шины запоминающего устройства — в боль- 
шинстве случаев это тип іп. Потоковая подсистема библиотеки о (файл Тһгеааѕ.һ) 
определяет тип Іп(Туре внутри каждой реализации стратегии тһгеааі помоае1. 

Элементарные функции, выполняющие атомарные операции, определенные в 
стратегии ТАгеа41 пдмо4е1, имеют следующий вид. 


хетріате <турепате т> 
с1аѕ5 Ѕотетһгеааіпдмоде1 


риБ1їс: 
туредеб 1пт тпттуре; // или другой тип в зависимости от платформы 
ѕтатіс Іпстуре АїотісАЯЯ (\о]ат11]е Тпетуре& Луа1, тпхтуре уа1); 
з5гасіс ІпсТуре АСопісб5ибсгаст(уоТатіїе тпттуре& Тмаї, тпетуре маї); 
аналогичные определения для функций Атотісми1т1ір1у, 
Атотіс0іуіде, Асотісіпсгетепіс и Атом1 сбесгемепт ... 

5схасіс №014 АтотісАѕ51ідп(уо1аїі1е Іп(Туреб Тма?, Іпїтуре уа1); 

з5зсхасіс моїд Атот1сА$$19п(тпттуре& 1ма1, уо1аті1е титтуре& ма1) 


; 

Эти элементарные функции получают изменяемое значение в качестве первого па- 
раметра (обратите внимание на то, что они передаются по неконстантной ссылке с 
помощью типа моТагсі Те), а второй операнд (отсутствующий в случае унарных опера- 
торов) передается в качестве второго параметра. Каждая элементарная функция воз- 
вращает копию параметра типа уо1атїі1е. Это очень полезно, поскольку позволяет 
контролировать фактический результат выполнения операции. Рассмотрим ситуацию, 
при которой переменная типа уо1аті1е проверяется после выполнения операции. 


моТасіТе іпт соиптег; 


б5отетігеадї пумодеї «мі ддес»: : Атоті сАаа (соиптег, 5); 

1Ё (соцптег == 10) 
В этом случае код не проверяет переменную соуптег сразу после сложения, поскольку 
другой поток может модифицировать ее в интервале между вызовами функции Афот1 сАаа 
и оператором 1+. Чаше всего проверять значение переменной соиптег необходимо сразу 
после вызова функции Атот1 сАЧЗа. Для этого достаточно написать следующий код. 


12 САтотісАаа(соиптег, 5) == 10) 


Наличие двух разных функций асопісад55ідп необходимо, поскольку даже опера- 
ция копирования может быть не атомарной. Например, если ширина шины компью- 
тера равна 32 бит, а тип Топд имеет размер 64 бит, для копирования переменной типа 
Топо понадобится дважды обращаться к памяти. 


П.4. Мьютексы 


Эдгар Дийкстра (Едраг Діікзїга) доказал, что в многопоточной среде планировщик 
потоков операционной системы должен содержать определенные объекты синхрони- 
зации. Без них написать правильное многопоточное приложение невозможно. 

Мьютексы представляют собой основные объекты синхронизации, позволяющие пото- 
кам получать доступ к совместно используемым ресурсам в организованном порядке. В 
этом разделе дается определение мьютекса. В остальной части библиотеки [оК мьютексы 
непосредственно не используются. Вместо этого в ней определяются высокоуровневые 
средства синхронизации, которые легко реализовать с помошью мьютексов. 
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Мьютекс (тщех) — это аббревиатура слов Миша! Ехс]изуе (взаимоисключающий), 
которые определяют способ функнионирования этого объекта. Мьютекс предоставля- 
ет потокам взаимоисключающий доступ к ресурсу. 

Основными функциями мьютекса являются функции АСсдиї ге и Ке]еазе. Каждый 
поток, которому необходим исключительный доступ к ресурсу (например, к совместно 
используемой переменной), завладевает мьютексом. Только один поток может владеть 
мьютексом. После того как поток завладел мьютексом, остальные потоки, вызываю- 
щие функцию Асдиї ге, переводятся в состояние ожидания (функция Асдиї ге ничего 
не возвращает). Когда поток, владеющий мьютексом, вызывает функцию Ве1еаѕе, 
планировщик потоков выбирает один из ожидающих потоков и передает право владе- 
ния мьютексом ему. 

Итак, мьютекс выступает в роли устройства последовательного доступа: часть кода 
между вызовом функции тех .АСдиїге( и вызовом функции ттх_.ке]еазе() явля- 
ется атомарной по отношению к объекту мех_. Все попытки завладеть объектом тех. 
откладываются, пока атомарные операции не будут завершены. 

Следовательно, для каждого ресурса, совместно используемого несколькими пото- 
ками, нужно предусмотреть отдельный мьютекс. В частности, такими ресурсами могут 
быть объекты языка С++. Каждая неатомарная операция, выполняемая над этими ре- 
сурсами, должна начинаться с захвата мьютекса, а заканчиваться его освобождением. 
Обратите внимание на то, что неатомарные операции содержат неконстантные функ- 
ции-члены объектов, безопасных для потока 

Например, представьте себе класс ВапКАссоип®, содержащий функнии рероѕіт и 
мітһагам. Эти операции представляют собой нечто большее, чем сложение и вычита- 
ниє полей класса, имеющих тип доче. Они также регистрируют дополнительную 
информацию, относящуюся к транзакции. Если к объекту класса ВапКАссоипе обра- 
щаются несколько потоков, то эти две операции должны быть атомарными. Для этого 
достаточно написать следующий код. 


сТа55 ВапКАСсСсоиПе 


риб'іс: 
\014 Оероѕітс(аоиБ1е атоипе, соп$® сһаг* иѕег) 


тех. Асаиіге(); 
... кладем деньги на счет... 
мех_.Ке]еазе(); 


уоіа мітһагам(аоиБ1е атоипе, соп5с сһаг* иѕег) 


{ 
тех .Асдиї ге 0; 
... снимаем деньги со счета ... 
тех. ке1еаѕе(); 


ргімате: 
митех міх; 

}; 

Возможно, вы уже догадались (если не знали этого раньше), что вызовы функций 
АСаЧЇ геи веТеаз5е должны строго чередоваться, иначе это может привести к печаль- 
ным последствиям. Если вы захватите мьютекс и не освободите его, то все остальные 
потоки, пытающиеся овладеть им, окажутся заблокированными навсегда. В предыду- 
щем коде при реализации функций рероѕіт и мітћагам следует быть очень внима- 
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тельным, предупреждая возможные исключительные ситуации и преждевременные 
выходы из функций. 

Для решения этой проблемы во многих прикладных интерфейсах языка С++ оп- 
ределяется объект і осК, который инициализируется мьютексом. Конструктор объекта 
тоск вызывает функцию адсаці ге, а его деструктор — функцию ве1еазе. Таким обра- 
зом, размещая объект госК в стеке, можно гарантировать правильное чередование вы- 
зовов функций Асаи1ге и ке|еазе даже в исключительных ситуациях. 

Для обеспечения машинной независимости в библиотеке Го сами мьютексь не 
определяются. Предполагается, что вы уже используете собственную библиотеку для 
поддержки многопоточного режима, в которой определены свои мьютексы. Было бы 
глупо дублировать их функциональные возможности. Вместо этого с помощью мью- 
тексов в библиотеке Го реализуется высокоуровневая семантика блокировки. 


П.5. Семантика блокировки в объектно- 
ориентированном программировании 


Объекты синхронизации связаны с совместно используемыми ресурсами. В объ- 
ектно-ориентированном программировании ресурсами являются объекты. Таким об- 
разом, в объектно-ориентированной программе объект синхронизации связан с объ- 
ектами приложения. | 

Следовательно, кажлый совместно используемый объект должен содержать объект 
синхронизации и блокировать его в каждой модифицирующей функции-члене, как 
это сделано в примере с классом ВапКАссоипт. Структура, в которой каждому совме- 
стно используемому объекту соответствует свой объект синхронизации, известна под 
названием блокировки на уровне объектов (ођјесі-1суе] ІосКіпе). 

Однако иногда хранить отдельный мьютекс для каждого объекта накладно. В этом 
случае следует применять стратегию, основанную на использовании только одного 
мьютекса для отдельного класса. 

Рассмотрим для примера класс ѕ1гіпд. Время от времени возникает необходи- 
мость блокировать его объекты. Однако мы не хотим хранить отдельный мьютекс для 
каждого объекта этого класса. Это привело бы к увеличению размеров объектов, и ко- 
пировать их стало бы неудобно. В этом случае для всех объектов класса 5сгіпд можно 
использовать один статический мьютекс. Как только какой-либо объект класса 5тг1пд 
выполняет операцию захвата мьютекса, она блокируется во всех остальных объектах 
этого класса. Эта стратегия нзывается блокировкой на уровне класса (с1азз-еуе] іосКіпр). 

В библиотеке ГоК определены две реализации стратегии тһгеааіпдмоде1: классы 
С1аѕ51 еме1 оскаБ1е и ОБ] естьеуе]тосКа Ле. Они инкапсулируют семантику блоки- 
ровки на уровне объектов и на уровне класса соответственно. 


хетріасе <турепате Но5 1» 
с1аѕ5 С1аѕ51 еме1іоскаБ1е 


{ 

риб11с: ' 
с1аѕѕ іосК І 
риБ1їс: 


оско; 
Госк(Но$Е& обі); 
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У; 


тетр1ате <сурепате Но$т> 
с1аѕ5 оБјеси еме1іоскаБ1е 


рибТіс: 
сТаз5 1оск 


рибТбіс: 
ІоскСноѕт& обі); 


}; 

}; 

С технической точки зрения объект класса і осКк оставляет мьютекс захваченным. Раз- 
ница между этими двумя реализациями заключается в том, что объект класса ОБбіестіе- 
ме ПосКабТехт»: :ГосКк нельзя создать, не передав ему объект класса т, поскольку в классе 
оБјеси еуе1іоскаБ1е используется стратегия захвата на уровне объектов. 

Объект вложенного класса іоск захватывает объект (или целый класс), связанный 
с мьютексом, на все время своего существования. 

В приложениях реализации стратегии Тћгеааіпдмоде1 играют роль базовых классов. 
Механизм наследования позволяет использовать внутренний класс госк непосредственно. 

с1аѕ5 мус1аѕ5 : риБ1іс С1аѕ51 еме1. оскаБ1е <Мус1аѕѕ> 


}; 
Точный вид стратегии захвата зависит от реализации стратегии тћгеадіпдмоде1, 
выбранной в качестве базового класса. Доступные реализации приведены в табл. П.І. 


Таблица П.1. Реализации стратегии ТигеадіпаМодеї 


Шаблонный класс Семантика 


5іпдТетігеадед Стратегия поддержки многопоточности не применяєтся совсем. 
Классы цосК и ВеадіосК представляют собой пустые макеты 


ОБіесцціеуеТоскабТе Семантика блокировки на уровне объектов. Каждому объекту 
соответствует свой мьютекс. Внутренний класс осК 
захватывает мьютекс (и, неявно, связанный с ним объект) 


СТаз $1еуе1 тоска] е Семантика блокировки на уровне класса. Каждому классу 
соответствует свой мьютекс. Внутренний класс ГосК захватывает 
мьютекс (и, неявно, все объекты связанного с ним типа) 


Как показано в следующем примере, синхронизированные функции-члены реали- 
зуются очень легко. 


с1аѕѕ вапКАссойпс : рибТіс објесі еме1оскаБ1е<вапкдссоипт> 


рчЬ1їс: 
моїд рероѕіт(адоиБТе атоипт, соп5є сНаг* иѕег) 


цоск ТоскС*еһћі5); 


кладем деньги на счет... 
шех_.Ке]еазе(); 
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моіа мітћагам(аоциБ1е атмоцпт, соп5с сһаг* изег) 


Боск ЛосКС+ћ15) ; 
снимаем деньги со счета ... 


}; 

Проблем, связанных с исключительными ситуациями и преждевременным выхо- 
дом из функций, больше не существует. Правильное чередование операций захвата и 
освобождения гарантируется инвариантами языка. 

Универсальный интерфейс, обеспечиваемый фиктивным интерфейсом $1п91етп- 
Һегітапсе, гарантирует синтаксическую корректность. Можно написать код, исполь- 
зующий многопоточный режим, а затем изменять проектные решения, просто меняя 
потоковую модель. 

Стратегия тһгеадіпдмоде1 используется в главе 4, Размещение в памяти небольших 
объектов, главе 5, Обобщенные функторы, и главе 6, Реализация класса 5іняіетоп. 


П.6. Модификатор уо!аШе 


В языке С++ предусмотрен модификатор типа уо1ат11е, с помощью которого лю- 
бую переменную можно предоставить в распоряжение нескольких потоков. Однако в 
однопоточной модели этот модификатор лучше не использовать, поскольку он не по- 
зволяет компилятору выполнять некоторые важные виды оптимизации. 

По этой причине в классе ГоК! определен внутренний класс мо1аті1етуре. Внутри 
класса ЗотетнгеаЧ1памо4де1<и14дет> класс МоТасіТетуре вычисляет объект типа 
уоТа{11е міддеє для классов СТа55 еме1іоскаБ1е и ОБ] естьеуе]оскаБЛе, а также 
простой объект класса м1Адет для класса $1па1етнгеадеа. Пример его использования 
был описан в главе 6. 


П.7. Семафоры, события и другие полезные вещи 


На этом мы завершаем обсуждение средств поддержки многопоточности в библиотеке 
Іокі. Обычные многопоточные библиотеки предоставляют программистам намного более 
разнообразные наборы объектов синхронизации и функций, например, семафоры, собы- 
тия и барьеры памяти (тетогу бапіегѕ). Кроме того, в библиотеке [о нет функций, акти- 
вирующих новый поток. Это еще раз подтверждает тот факт, что библиотека [041 обеспе- 
чивает безопасное выполнение потоков, но не использует сами потоки. 

Возможно, в будущих версиях этой библиотеки будет реализована полная потоко- 
вая модель. Многопоточность — это область, в которой обобщенное программирова- 
ние проявляет всю свою мощь. Однако в ней сильно развита конкуренция — в каче- 
стве прекрасной машинно-независимой библиотеки для поддержки многопоточного 
режима можете применять среду АСЕ (АдарНуе СоттипсаНоп Епуігоптепі — адап- 
тивная среда для обмена информацией) (Ѕсһтіає, 2000). 


П.8. Резюме 


В стандарте языка С++ потоков нет. Однако вопросы, связанные с синхронизаци- 
ей многопоточных программ, значительно влияют на разработку приложений и биб- 
лиотек. Разные операционные системы поддерживают разные потоковые модели. По 
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этой причине в библиотеке |Гокі определен высокоуровневый механизм синхрониза- 
ции, поддерживающий минимальное взаимодействие с внешней потоковой моделью. 

Стратегия тһгеадіпдмойе1 и три шаблонных класса, реализующих ее, образовывают 
основу для создания обобщенных компонентов, поддерживающих разные потоковые мо- 
дели. На этапе компиляции можно выбирать стратегию блокировки на уровне объектов, 
стратегию блокировки на уровне классов или не применять блокировку вообще. 

Стратегия блокировки на уровне объектов создает отдельный объект синхронизации 
для каждого объекта в приложении. Стратегия блокировки на уровне класса ‘создает от- 
дельный объект синхронизации для каждого класса в приложении. Первая стратегия обла- 
дает более высоким быстродействием, вторая использует меньше ресурсов. 
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Ѕїогаре, 39; 183; 209; 210 
Зігистиге, 39 
Тьгеади = Моде|, 37; 171; 321 
владения . 
глубокое копирование, 185 
копирование при записи, 186 
подсчет ссылок, 187 
разрушающее копирование, 190 
связывание ссылок, 189 
ортогональность, 38 
проектирования, 30 
совместимость, 39 
Структура 
Аррепа, 79 
СотрИеТипеСвескКег, 47 
СотрйеТипеЕпог, 47 
Пепуе4ТоЕгои\, 85 
Егазе, 80 
Ноїаєг, 91 
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ІавхоОї, 78 
Гепа, 76 


МетСопио Воск, 101 


Мові Дегіуеа, 85 

МорДиріїсагез, 82 

ОрМемСтеатог, 34 

Керіасе, 83 

ТуреАї, 77 

ТуреАМопбігісі, 77 
Сцеплениє, 143 


У 


Указатель 


управление владением, 181 
интеллектуальный, 26; 179 


константный, 204 


на константный объект, 204 
способ хранения, 183 
ссылочный тип, 183 


тип указателя, 183 
на функцию-член, 137 


отношения порядка, 200 


преобразования, 193 
проверка 


во время инициализации, 202 
перед разыменованием, 203 


сравнение, 195 


Ф 


Фабрика обьектов, 218 
Функция 
Ассері, 260; 267 
АссерИтр!, 271 
Асбіоп, 123 
Ааа, 298 
АПосаїе, 104 
А ЕхиРп, 167 
Атотіс Ресгетепі, 207 
АїотісІпсгетегі, 207 
Віе Віазі, 62 
ВіпаЕігѕї, 143 
Сазі, 305 
Сћаіп, 144 
Сіопе, 186 
Сору, 61 
Сгеаїе, 31; 53 
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СгеаќеЅһаре, 225 
РеаПосже, 104 
Резкоу$пеоп, 174 
РДізраєі ВИ», 287 
Гізріаубтацяйся, 260 
Ехесше, 123 

Бісі4, 89 

ҒіеІаНе1рег, 91 

Се тр, 184 
Сейтрікеї, 184 
СеРгоотуре, 31 

Со, 287 

Іпіє, 104 

Іпѕќіапсе, 174 
МаКеАЧариег, 50 
таПос, 30 

Оп Опкпо\пТуре, 228 
Ке|еазе, 184 

Кезег, 184 

5аїе геіпіегргеї сазі, 48 
5екЇ опреміту, 162 
ЗеРгооуре, 31 
МізісРагавгарі, 267 
виртуальная, 33 
воплощенная, 260 
ловушка, 262 
перегруженная, 54 
трамплинная, 297 


Х 


Характеристика, 30; 61 
ізРгітійме, 65 
КеѓегепсеаТуре, 65 


Ц 


Циклическая зависимость, 163; 263 


по имени, 263 


Ш 


Шаблон проектирования 
Абвігасі Кастогу, 71; 239 
АсусПс Міѕіїог, 264 
Соттапа, 122 


Доцбіє-Срескей Госкіпе, 168 


Моповзіате, 152 


Предметный указатель 


Рроепіх 5іпеієтоп, 159 конкретизация, 49 


Ргоюгуре, 249 частичная специализация, 49 
5іпвістоп, 151 явная специализация, 48 
Тпріе-Срескед ГосЮ шв, 170 Шаблонный параметр 
Усіќог, 71; 255 обычный, 29 

Шаблонный класс шаблонный, 32 
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